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Foreword 


Programming languages have been state-based since their inception. After a period of relative 
unpopularity, when research focused on declarative languages, interest in the treatment of state 
has been renewed. Research is increasingly devoted to finding a symbiotic relationship between 
the semantic foundations of declarative languages and the pragmatic handling of state in more 
conventional languages. 


The ACM SIGPLAN Workshop on State in Programming Languages brings together researchers 
from various areas interested in the common issues of state manipulation in high-level programming 
languages. The first workshop in the series (SIPL ’93) was held in Copenhagen in June, 1993. This 
proceedings contains the papers presented at the second workshop (SIPL ’95) held on January 22, 
1995 in San Francisco, California. 


We received ten submissions in response to the electronic call for papers, all of which were of very 
high quality. The program committee recommended seven submissions for presentation at the 
workshop. All these papers appear in this proceedings. 


I would like to thank the members of the Program Committee for their timely reviews within a 
short time frame. Special thanks go to my co-organizer, Peter O’Hearn, and to Bonnie Howard 
for assistance at University of Illinois. We thank ACM SIGPLAN for agreeing to sponsor this 
event and to Ron Cytron and his crew for the joint organization with POPL. Finally, thanks to 
Jonathan Springer for putting SIPL on the world wide web. Please watch this web page for future 
announcements related to SIPL: “http://vesuvius.cs.uiuc.edu:8080/sipl/index.html”. 


Uday S. Reddy 
SIPL Program Chair 
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Formalizing Hoare Logic * 


Joshua E. Caplan 
Department of Computer Science 
University of Illinois at Urbana-Champaign 
caplan@cs.uiuc.edu 


December 22, 1994 


Abstract 
We present a new formalization of Hoare Logic (using the Edinburgh Logical Framework [5]) 
and examine the issues raised. Our approach improves upon current LF representations of 
Hoare Logic and, via the LF type theory, generates for free a logic for a fragment of Idealized 
Algol [13], including proofs about procedures. 


1 Introduction | 


In this paper, formalizing a logic L means defining a signature U, in the language of some meta- 
logic, like the Edinburgh Logical Framework (LF) [5], such that L; adequately represents L. L is 
called the object logic, and U, its representation or encoding. There are (at least) three benefits to 
formalization of a logic: 


1. Philosophical: The search for an adequate encoding usually brings to light important prop- 
erties of the object logic. 


2. Theoretical: Through the expressive power of the meta-logic, we obtain from the encoding a 
non-trivial, yet decidable and conservative extension of the object logic. 


3. Practical: We can plug the encoding into any existing implementation of the meta-logic to 
immediately obtain a proof checker and/or theorem prover for the object logic. 


We will describe a new formalization of Hoare Logic in LF which improves on those which exist 
in the literature, and in so doing illustrate all of the above benefits. 

The first will surface when we elucidate the property of Hoare Logic which inhibits a straight- 
forward encoding, motivating the creation of new syntax and two new calculi which repair this 
defect without fundamentally altering the notion of provability. 

The second will appear when we then formalize one of the new calculi and obtain, by virtue of 
the LF type theory, a logic which allows us to reason about proper procedures as well as simple 
commands, and to reuse the proofs for their calls, as long as the active arguments don’t interfere 
with the procedures. This proviso is the basis of Syntactic Control of Interference [9, 10, 14], so 
it is not surprising that our system has some features which seem to correspond to aspects of the 
typing system of P. W. O’Hearn and R. D. Tennent [9], although we arrived at our techniques 
independently of their work. 

We have exploited benefit number three to mechanically verify the examples in section 5. 


“This work partially supported by NASA grant NAG 1-613 (I-CLASS) 
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1.1 Related Work 


There are two published formalizations of Hoare Logic in the LF, which appear in [3, 7]. Hoare 
Logic is not easy to formalize because weakening and contraction are admissible rules in the LF, 
which can lead to certain invalid formulas of the naive encoding being inhabited (see section 2.1). 

In the first formalization, new judgment forms denoting non-interference and non-identity of 
program variables are used to express a correct assignment axiom. This approach is reminiscent 
of J. C. Reynolds’ Specification Logic [11, 13], but as a result seems not to be an entirely faithful 
representation of Hoare Logic. For example, having obtained a proof term ¢ in a context [ = {z,y: 
var,z: 2 tar ¥,2" : y tvar Z} as prescribed by I. A. Mason in [7], contraction yields ¢[z/y] in 
context I’ = {zr : var,z,z* : 2 tyvar z} which may correspond to some non-existent proof in Hoare 
Logic (based as it is on flawed assumptions). 

In the second formalization, program variables used in Hoare triples are bound by the LF \X. 
All rules are given relative to these bound variables, so in order to have a finitary LF signature, the 
number and order of those variables must be fixed and finite. Thus the formalization is a family of 
signatures, one for each choice of variable set, and each one turns out to be adequate for a fragment 
of our calculus QHLo (section 2.3), but certainly not for full Hoare Logic. 

The signature we give neither employs auxiliary judgments about non-interference nor fixes the 
set of program variables in advance. We avoid these pitfalls, and admit far greater extensibility, by 
unabashedly modifying the object logic before encoding it, incorporating a disguised form of affine 
contexts. Such contexts for program variables have appeared in earlier work, e.g. [9], and other 
researchers have found it natural to reformulate a program logic before formalizing it [6]. 


2 Repairing Hoare Logic 
2.1 Hoare Logic 


Recall the usual natural-deduction formulation of Hoare Logic (Table 1), defined relative to an 
underlying first-order language Z and first-order L-theory of expressions T. There is only one 
judgment form, asserting the validity of a Hoare triple. The other judgment form which appears 
in the rule of consequence (Con) is that of T, so we consider Con to be schematic not only in the 
meta-variables P’, P,Q,Q’,c but also in the derivations of the L-formulas P’ > P and Q => Q’. 
As presented, there are no “closed” Hoare triples, because every program must contain at least one 
assignment (with a free identifier). 

Notice that free identifiers in first-order formulas are implicitly universally quantified; a for- 
mula’s validity is immune to substitution because universal elimination is a sound rule in first-order 
logic. Free identifiers in Hoare triples do not enjoy the same genericity. For example, the triple 
oe {true} z:=y+1{y < x} is valid, but ¢[z/z, z/y] = {true} z:=2z+1{z < z} is not. Validity 
is not preserved by substitution in Hoare Logic. 

In the simple programming language of Hoare Logic, substitution never arises, and all distinct 
identifiers implicitly denote non-interfering program variables; that is, assigning to one will not 
affect the value of the other. In a language with procedures, such as Algol, the assignment axiom 
breaks down because substitutions occur with each procedure call. The higher-order nature of the 
LF also permits substitution, but the inhabitability of any type in the LF is always preserved; thus 
we cannot directly encode the form of Hoare Logic given in Table 1. 

Instead, we give an essentially equivalent formulation of Hoare Logic which is amenable to 
formalization. LF substitution then includes the copy rule of Algol, so our resulting system handles 
procedures, too. 


{Pye{Q} {Q}d{R} 


(Assign) {P[t/a]}a:=t{P} (Seq) {P}c ; d{R} 

{PAb}c{Q} {PA-b}d{Q} qe eae ae yetPy ot, 
ay (Pian echanececlPoliO en dee WAT?) while dedove( PA 0} 
(Con) P>P {P}c{Q} Q=>Q 


{P'} ¢{Q'} 


Table 1: Hoare Logic. 


2.2 Quantified Hoare Logic: Syntax 


Definition 2.1 Let Z be a first-order language, V the set of variables, E the set of Z-terms, F 
the set of Z-formulas, and Q the set of quantifier-free L-formulas. The set of formulas (spec) of 
Quantified Hoare Logic (over L) is given by the following grammar: 


(command) ::= V:=£|((command) ; (command)) | 
(if Q then (command) else (command)) | (while Q@ do (command)) 
(spec) = {F} (command) { F’} | VV (spec) 


We call the formulas of Quantified Hoare Logic specs. It is obvious, but nevertheless important, 
that every spec consists of zero or more Y-binding identifier occurrences (the prefiz) followed by a 
Hoare triple (the matriz). 


Definition 2.2 Substitution is defined for Quantified Hoare Logic just as for Hoare Logic, except 
that ¥ is a binding operator. 


2.3 The Calculus QHL,) 


The most natural proof calculus for Quantified Hoare Logic, called QHIo, is given by the axioms 
and inference rules of Table 2. We say Fy ¢ just in case ¢ is derivable via the rules. 

In this calculus there are no “active open” derivable specs, i.e., the active identifiers are all bound 
by VY (Lemma 2.4). Observe that the quantifier ¥ does not act as a medium for instantiation, as 
does the universal quantifier of first-order logic. There is no analogous Y¥-elimination rule in QHLo. 
Rather, through the assignment axiom, we force identifiers appearing on the left-hand sides of 
assignments in the command portion of derivable specs to be bound by ¥. The prefix acts as a 
context keeping track of actively-occurring identifiers (and protecting them from substitutions). 
Within any QHLp derivation, every triple will have an identical prefix. 

Having changed the language and proof system of Hoare Logic, it is desirable to know that we 
have not fundamentally altered the notion of provability. 


Definition 2.3 An identifier which appears on the left-hand side of an assignment in a spec is 
called active in that spec. 


Lemma 2.4 Specs derivable in QHLo have no free active identifiers. 


Proof. By an easy induction on derivations. O 


vE{P}c{Q} Vz{Q}4{R} 


(Assign m) VE(Pifealieasat(P} (Sean) ve {P}e; d{R} 

VF{PAb}c{Q} WF{PA-b}d{Q} teddy halen ETE AO) le a 
(If, )  Wi{P}if 6 then c else d{Q}_ we) Vi{P}while b do c{PA-6} 
(Con, ) PeP VetPieiQ} Go 


vz {P’} c{Q’} 


m,néew,0<n,l<em<n, F=2z...2, in all rules 


Table 2: Calculus QHL, for Quantified Hoare Logic. 


Proposition 2.5 Let ¢ be a spec, its matriz, X the set of identifiers bound in its prefiz, and A 
the set of its active identifiers. Then 


(Ho ¢) => (kup GA AC X). 


Proof. (<==) Remove the prefix from every spec in a QHL» derivation of ¢, and apply Lemma 2.4; 
(==>) add the prefix to every triple in a Hoare Logic derivation of ¢. Oo 


Theorem 2.6 The provable formulas of QHLo are closed under substitution, i.e., for any formula 
@ of Quantified Hoare Logic df 
bo db => Fo Oft/Z]. 


Proof. Without loss of generality, we show that for any Hoare triple ¢, collection of distinct iden- 
tifiers Z,y, and term s not containing Z free, 


Fo Vid => by VF¢[s/y]. 
The proof proceeds by induction on derivations: 
Base Case ¢ = {Plt/tm]}2m:=t{P}. Then 
(Vzo)[s/y] VE {P[t/tm][s/y]} tm = t[s/y] {Pls/y]} 
VE {P[s/y][t[s/y]/2m]} tm := t[s/y] {Pls/y]}, 


which is derivable by the assignment axiom. 


Induction Step Follows routinely from the definition of substitution. O 


Unfortunately, this calculus does not lend itself to formalization. In the LF, an inference rule 
is represented as a constant whose type, schematic in the meta-variables of the rule, is the type of 
maps from proofs of the antecedent judgments to proofs of the consequent judgment. But the type 
system of LF cannot express the rules of QHLy as types schematic in n and m, because the physical 
shape of the formulas in the antecedent and consequent vary in those meta-variables. Therefore 
each rule in Table 2 would require infinitely-many constants in an LF signature, one for each n and 


m. Because infinite-length signatures are not permitted, we must develop a more homogeneous 
calculus. 


YzVyo 


(VIntro)" eR (Exch) Vy¥ao 
(v] HiFleao ° 
(VIntroUn)* ae (VIntroBin)* Bok prin ty VR yas UE. — Me 
, {Phe{Q} {Q}d{R} 

(Assign) Vz {P[t/z]}a:=t{P)} (Seq) {P} a: di R} 

{PAb}c{Q} {PA} d{Q} ebewakie OuR) Gadel ater 
(If) Fp witieen aie Gna ri ere 
(Con) Boh ea 


{P'} c{Q'} 


“Provided z is free only in ¢ and/or the discharged hypothesis occurrences. 


Table 3: Calculus QHL, for Quantified Hoare Logic. 


2.4 The Calculus QHL, 


Such a calculus is given in Table 3. We denote derivability in QHL, by +;. The rules are clearly 
divided into structural rules, including the VIntro rules and Exch, and the compositional rules, 
comprising the Hoare Logic analogues. The proof-theoretic equivalence of QHL) and QHL, is the 
main theorem of this section. 


Theorem 2.7 For any spec ¢,+) 66>, 6. 


Proof. To prove the => direction, we show that the rules of QHLo are all derivable in QHL,, 
inductively applying structural rules to add bindings to the compositional rules. In the case of 
Assign, m we must use the Exch rule. For example, 


[{Pye{QH [{Q}4{R}] . 
{P}c;d{R} 9 We{P}c{Q} vz {Q}d{R} 


Ya {P} a d{R} (vIntroBin) 


represents Seq. 
To prove the <= direction, we observe that the compositional rules of QHL, are all special 


cases of their counterparts in QHLo, and that the structural rules are all admissible (though not 
derivable) rules of QHLo. O 


Thus the provable specs in QHL, are just the provable triples of Hoare Logic with (at least) 
their active identifiers bound by Y. Intuitively, the reason QHL, is equivalent to QHL, is that there 
are only three kinds of rules in Hoare Logic: axioms (0 antecedents), unary rules (1 antecedent), 
and binary rules (2 antecedents). Thus we only need two YIntro rules to generate the inference 


rules of QHL, from plain Hoare Logic, and a third VIntro rule and Exch to get the assignment 
axioms. 


Corollary 2.8 The provable formulas of QHL; are closed under substitution. 


In this calculus, the contextual role of V is transparent. Notice that we have weakening (rule 
VIntro) and exchange (rule Exch and its many derived forms), but no contraction or elimination. 
Evidently from the example in section 2.1, contraction lies at the root of the problem with sub- 
stitution in plain Hoare Logic. When substitution becomes formally available in the next section, 
the omission of elimination rules for ¥ from the calculus will be essential in obtaining semantic 
adequacy. 


3. The Formalization 


We define our signature assuming encodings Lroz of first-order logic and Uz of a finitely- 
axiomatizable first-order theory T. 
3.1 Syntax 


We assume the type constants exp for terms of T and assert for formulas of T are defined in Yop. 
Within Uror are purely logical constructors, including 


= : exp — exp — assert 


— : assert — assert 
=>,A,V : assert — assert — assert 
V,d : (exp — assert) — assert 


and Lr contains constructors of the form 


c : exp 
n 
een 
f : exp—...—exp— exp 
m 
ro: exp—...— exp — assert 


for each non-logical constant c, n-ary function symbol f, and m-ary predicate symbol r of T. 
The syntactic categories of Quantified Hoare Logic are easily declared: 


var,comm, spec : TYPE 


We follow Mason [7] in declaring a separate type var for program variables and giving no 
constructors for it, but only a coercion 


7 : var — exp, 


forcing the only normal forms of type var (in ground contexts) to be LF identifiers. The syntactic 
judgment QF will be discussed in the next subsection. 
Command and spec constructors look like 
:= : var — exp — comm 


>» » COmm— comm — comm 


if : [[b-assere QF (6) + comm — comm — comm 
While : [Jp.assere QF(6) —~ comm — comm 
{-}-{-} : assert — comm — assert — spec 
Y : (var — spec) — spec 


We will freely use infix for operators like = and :=, postfix for the | operator, and the abbrevi- 
ation Yr @ for ¥(Az.¢) in what follows. 


3.2 Judgment Forms 


There are three: validity of an assertion in the underlying first-order theory T, validity of a partial 
correctness formula H, and a syntactic judgment QF first seen in [7] which indicates that an 
assertion is quantifier-free and can be used as the conditional expression in an if or while command. 


T,QF : assert —- TYPE 
H : spec— TYPE 


3.3. Axioms and Inference Rules 


The rules of QHL,, translated into the formalism of the LF, and the rules concerning QF are shown 
in Table 4. 


3.4 Adequacy 


Call the signature obtained from combining Lpo,, Lr, and the preceding declarations OU OHL: 


Theorem 3.1 (Mason [7]) The signature UO OHL is syntactically adequate for Quantified Hoare 
Logic with respect to contezt 


dfn 
1 le VALI 2. oy SVEr |, 
1.e., for each type 6 = var, exp, assert,comm, spec there is a compositional bijection T, between 


well-formed LF @n-normal forms of type 6 and expressions of the corresponding syntactic category 
(with free identifiers among those inT) in Quantified Hoare Logic. 


Theorem 3.2 The signature ORL ts semantically adequate for QHL, with respect to the empty 
context, i.e., for every spec @ there exists a compositional bijection Ty between well-formed LF 
Bn-normal forms of type H(@) and derivations of ¢ in QHL. 


Proof. An uninteresting pair of inductions on normal forms and expressions. oO 


We abbreviate argument lists z,[ raf ... z,[ to ZT. We have the following as a corollary to the 
adequacy theorems and the proof of Theorem 2.7: 


Corollary 3.3 The following are derived inference rules, for each 1 <m<né€w: 


n 


AsgnAXnm lpaeiiee Paro essere |) hemos teccarat lis 
Bie tia viet Gone cal eh cha it) Theil -e Salt teu = (t 2) {P zt}) 
n n 
SeqRule, Bein Cnc varieceare | ob eee rare aiaaeee 


HUVapwe’rn or ten 1g 2h) 
H(Vz,...¥z,{Q z}dz{Rz}) — 
BV eie ove ar Seer 24 | 


nn eee SUE UyU EEE SEES ESSERE 


QF= : {Taexe QF(t a w) 


~QFr "2 Thi, tnrexp EO Et oe dam [r an m-ary pred. sym. from T] 
QF- : Viv aseare QF(d) er QF(-4) 
QFx + Tasamere QF(a) + QF(b) + QF(a x 5) be = VI 
AsgnAx, 1 : Li p-axt-3 asdeet heat ah 


H(¥(Az.{P(tz)}2:=tr{Pzt})) 

SeqRuley : [1p¢,r:nssert 19) Desay sin 
H({P}c{Q}) + H({Q}d{R}) — H({P}c; d{R}) 

IfRuleo : Ip b,Q:assert 14 d:comm bE: QF(b) 
H({P A 5} c{Q}) — HP A 7b} d{Q}) + H({P} it bscd{Q}) 
WhileRuleo : lp yaneers Te ccmeen Il, -qF(0) 

H({P A b}c{P}) + H({P} whilebsc{P A -5}) 

ConRuley : Wes oe [le ae Mie! +" se zx T(Q ¢ Q') ws 
H({P}¢{Q}) — HP} c{Q"}) 


Exch |'l}:var- vanes 
A(¥(Az.¥(Ay. fz y))) + H(W(Ay.V(Az. fz y))) 
VintroA xt, sl ¢austeee. 
(Hever H(f%)) > H(¥ f) 
WintroUnv ei ll jevecses 
(Tlewwar H(f 2) + H(g 2)) + (H(¥ f) — HCW 9)) 
WintroBin. rt ]/] pee ee ee 


(Tlevar H(f 2) - H(g 2) — H(hz)) — (H(V f) — H(¥ 9) — (vA) 


Table 4: Axioms and Rules of Udur- 


IfRule, . yy eeseaterrins eer Ih demerit ante 2 I1,.(Ty.ver QF (0 g)) 
H(¥2,...¥tn {PEA ba} cF{Q z}) > 
H(¥2,...V2,{P ZA 7(bz)}dz{Q Z}) + 
H(V2; ...Wzn {P @} if (b#) (9 #) (c#) (42) {Q 2}) 
WhileRule,, : i 63 Coreyierree oy ty Cem Seer cere T],.(HyvaeQF (0 9)) 
H(Y¥2; ...Viniit AZ cl 1L Z}) = 
H(¥2)...Vin it 7) wnile(oz)(3z)(cz){PzA-=(bz)}) 
ConRule, : Te’ 7.0.0: a assert ||) ke eee rae ioe ern 
H(V¥2,...¥2,{Pz}cz{Qz}) — 
H(W2,...V2, {P’ Z}cZ{Q! 5}) 


A proof of this corollary can be obtained by directly translating half of the proof of Theorem 2.7 
into LF. The example given there becomes the LF term 
AP, Q, R, ¢, ds WIntroBind Aza:f Pz} cz{Q-z}) 
(Ani cy; aan cy) 
PXgete er ecen dcr) 
(Az .SeqRulep (P rz) (Q rz) (Rez) (cz) (dz)) 


which has type 


Ile, R:var— assert [dds d:var— 
H(V¥z {Pr}er{Q ae _ - H(¥2 {Q t}de{Rr}) ~H(V¥e{Pr}cr ;dzr{Rr}) 


and is thereby worthy of the name SeqRule. 


Proposition 3.4 For any permutation o on1,...,n, with n > 2, the rule 
Exch, a]. be ‘Var—...—Vvar—spec 


Hi yz, avr ier) — Bercy hia) Fie 


ts derivable. 
Proof. First, we derive Exch, » for each 1 < m < n Ew, of type 


—_——} 
Exch m Il, ‘var—...—var—spec 


H(Vz,...Vz, ff) > 
Fas aren di Voit Pan Gate ee Ul nal ©); 


by induction on n: 
Base Case Exch2, a Exch 


Induction Step We assume the terms Exch, for all m:1<m<n. Then 


n 


Exchagim Af. EXxcham (AZ. Vy f Zy) 
(oral mail isem ican); 


dfn 


Exchay aS PNT Cy initro Un geval) Ve Pf yz) 
PA See ete wr ef Ur) 
(Ay. EXC tg OE y)) 


Because we can decompose any permutation o into a sequence of such transpositions (Bubblesort 
comes to mind), composing some of the terms derived above will yield Exch,. Oo 


One might complain that the ubiquitous subscripts appearing on the names of primitive or 
derived inference rules present a greater bureaucratic headache than the non-interference judgments 
of [7]. In a real implementation, most of these subscripts could be inferred from the types of the 
arguments; in an implementation of Mason’s system, the non-interference proof obligations at 
each use of the assignment axiom can be mechanically derived, but depend on a plethora of non- 
interference assumptions in the context. It is a matter of personal taste. 


4 Extensions 


4.1 Local Variables 


The rule for local variable declarations is relatively easy to add. In Hoare Logic it looks like 


{P Ay = e}cly/z] {Q} 
{P}new r:=e ; c{Q} 


(see [1]). In LF it is rendered as 


NewRule, ; : IIp ,Q: assert Gb :var—comm ite :exp 
H(Wy{P yt =e} cy {Q}) — H({P} new e c{Q}) 


where the new command constructor 


where y is not free in P, e, c, or Q 


new: exp — (var — comm) — comm 


has been added to the signature. We have enforced the side condition of the informal rule by 
making the type of P and Q be assert, rather than var — assert as in the assignment axiom. 
This way, LF @-reduction prevents anything in P or Q from referring to the bound y. 

Similarly to the proof of Proposition 3.4, one can derive 


n-1l n n 
NewRule,, m alte Q: Walco avant Gasert Tie atasieeeVarae contin He a 
H(Wapei Van {(P{E\2m)) A cht = (e(f\ tm))}eF{Q (Z\ tm)}) > 
H(Vzr, a WV Dmat lel os a, 


{P (Z\ tm)} new (e(Z\ tm)) (Atm -¢ 2) {Q (Z\ 2m)}) 


for al 1 < m < n € w, where (f \ z,,) abbreviates x, es Ome, Emi - = (2n— iiiwerantdetie 
informal equivalents of NewRule,,,, to QHLo and NewRule,, to QHL,, we again have analogues 


of Proposition 2.5, Theorems 2.6 and 2.7, and Corollary 2.8. The adequacy theorems go through 
just as easily. 


4.2 Data Types 


Adding additional base types involves changing T into a multi-sorted theory and properly en- 
coding it in Lr. Perhaps the cleanest technique is to add constants DataType : TYPE and 
6: DataType for each data type 6, and modify the types of the two constants 


var,exp: DataType — TYPE. 
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The term formation constructors, axioms, and inference rules can take an additional parameter 
D : DataType describing the sorts of expressions to which they are being applied, as in 
Wrire TIp:patatype( Var( D) — spec) — spec 


AsgnAx; 1 : [Ip-pataType Il pene Diss escort TieeptD ead) 
H(V¥pz{P(tzrtp)}2:=p tz[p {P rTp}). 


We will not use data types in the remainder of the paper. 


4.3. Induction 


The LF is an open-ended framework, meaning that one cannot automatically deduce that the only 
inhabitants of a certain type are those built from constructors in the signature. An example of this 
incompleteness as it pertains to our signature Udy, is provided by the following proposition. 


Proposition 4.1 Under signature OOuL and in the empty context, the LF type 


Vacuous ©" [].var-comm H(¥y {yt # yt} ey {yt = yt}) 


is not inhabited. 


Proof (sketch). Suppose there were a term p such that Fur p: Vacuous. Without loss of generality 
assume p is in canonical form. Then 


Kur p(Ay.y:=yt) : H(Vy {yt 4 yt} y:= yt {yf = yT}) 
Kir p(Ay.y:sytsyssyt) : A(vy{yl A yt} y:eyT s y= yt {yt = yT}). 
Line 1 implies that p contains no occurrences of the rule SeqRuleg, but line 2 implies that p contains 


exactly one occurrence of SeqRuleg. O 


Clearly the type Vacuous corresponds to an admissible (though not derivable) schema of QH1I). 
The proof of admissibility depends on an induction over the form of the command c. We therefore 
add to Udur the rule constant 


SpecInd, : to ae 
(Teexp-exp H(f (Aw. :=t21))) = 
(Teavar-comm H(f c) — H(f d) + H(f (Av.ex ; dz))) — 


(Ero sadears I1,.( yeep QF(O y)) bl ronan 
H(f c) — H(f (Az. while(b 21) (sf) (ez)))) — 


(itera IT,.( Teer QF(O y)) lees eens 
H(f c) + H(f d) — H(f (Az. if (62?) (s 21) (ex) (dz)))) — 
ti ove se H(f c): 


The soundness of this rule follows from the characterization of canonical forms in LF [5, Lemma 


2.10]. Using it we can easily construct a term of type Vacuous, and we can derive the Invariance 
Axiom 


ipa oete hiesam eis! H(¥a LLP cr {P}). 


Note that the logic is still incomplete (i.e., it is not possible to derive all the admissible rules of 
QHL,), for we cannot apply this rule to, say, higher-order judgments. 
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5 Examples 


The reward for our endeavors arises from the full power of the LF as applied to the signature 
Loui; by identifying the LF A and — with those of Idealized Algol [13] we can form terms (and 
corresponding proofs) of higher types. In this section we assume that T, the first-order theory 
relative to which the assertion calculus is defined, is Peano Arithmetic. 


5.1 Factorial 


A procedure for computing the factorial of a number 7 and assigning it to the variable f is 


fac oP Ai.Af.newt(An.f:=1; 
while (>n{ = 0)(QF- (nf = 0)(QF=nf 0)) 
(f:= ffx nt; n:=nt-1)) 
fac : exp — var — comm 


The following term, with reconstructible or assumed subterms elided to -, proves the partial 
correctness of fac. 


Fac 2 \R. Ai. NewRuley» (Af. R)(Af-RAf =i!)-- 


(ConRule, ate Ta. egos 
(SeqRule.-----: 
(AsgnAx. ; OS ) 
(WhileRule. (Af.An. RA fxnt=i)--- 


(ConRule.------- 
(SeqRulez (Af.An. RA(f xn) x(n—-1)l=i!)---- 
(AsgnAx21- -) 
(AsgnAxe,2- - )))))) 


Fac : [lakeseee [fen H(W f {R} faci fi {R \ fT = i!}) 


The assertion R, which appears in the pre- and post-condition, cannot access the bound variable 
f or the local variable n; thus we have shown something slightly stronger than is possible (formally) 
in Hoare Logic, namely that the active area of the factorial procedure is limited to the variable f. 
Furthermore, if we intend to reuse this proof (see the next section), R will enable us to enlarge the 
active area referred to by the pre- and post-condition. 

Observe that the passive argument 7 is bound by [], whereas the active argument f must be 
bound by Y in order to construct the proof. This pattern occurs in general when reasoning about 
proper procedures (those whose return type is comm), in light of Proposition 2.5. 


5.2 Choose 


A procedure for computing m choose k and leaving the result in c is given by 


choose “© Am.Ak.Ac.new0(Aa.fackc ; 


fac(m—k)a;c:=cl xaf ; 
facma ; c:=af/cf). 
choose : exp — exp — var — comm 


We can specify the partial correctness of this procedure in terms of the proof Fac from the 
preceding section. Although the type of the proof term Choose below has only one Y-bound 
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identifier, most of the proof is carried out inside of the bindings Vc¥a. The Fac proof shows only 
one binding, Wf. In order to use Fac for the three calls to fac within the proof Choose, we will need 
to invoke structural rules YIntroAx and Exch to properly instantiate the active variable f, viz., 


Fac), Ri Exch -(WIntroAx:(Ac.FacRi)) : H(¥e¥Va{R}facic{R Act = i!}) 
Facy.. Ri“ VIntroAx- (Ac. Fac Ri) : H(¥cVa{R} facia{RA at =ii}). 


The skeleton of the proof term looks like 


Choose @ NewRulez.:--:-: 
(SeqRule,----- 
(SeqRule,----- 
(SeqRule.:---- 
(SeqRule.:---: 
(ConRule.:-----:- (Face -)) 
(ConRule.----+--- (Fac2,2 -(m — k)))) 
(AsgnAx>,1 + - )) 
(ConRuleg:-----:- (Fac2,2-m))) 


(AsgnAx. 1 Die )) 
Choose : [In t-exp H(Ve {k < m} choose mk c {et ca (i) by, 


5.3. Interference Control 


In the case of procedures with multiple active arguments, the built-in limitations of the structural 
rules provide a weak form of interference control. Suppose we have a proof 


Rol eee Pty ent Lt he FL 21Y bh) 


about procedure r whose active arguments are represented by y in R, and we wish to use R to 
construct a proof term 


OA eer Hive (italy... rth... (Qa 2] yy, 
where @ C Zand ¢ are all of type exp. We must apply structural rules to R to obtain a term 
R' : Lites H(V¥z{P, = vt} Ti vis = vt}), 


because the rules for compound commands which we will use to construct C’ expect identical prefixes 
in their antecedents. (If r occurs within k new commands, then k additional active identifiers will 
be needed in the prefix.) We can rename the identifiers in the prefix in the type of R by virtue of 
LF’s definitional equality; the structural rules will permit arbitrary expansion and rearrangement 
of the prefix, but they provide no means for contraction to occur. Globals in the body of r can 
be treated as additional active parameters. Therefore v must all be distinct (i-e., non-interfering) 
identifiers, and % must not interfere with r, in order for us to use R in the construction of C. 
Finally, apply R’ to the arguments ¢ and abstract over w to obtain 


AG. R'E: Taexp H(VE{P, Cot} r FT {Q, Fot}) 


which can be used as an antecedent in some compositional rule. 


Li 


Reasoning about interfering identifiers is not completely precluded, however. For example, an 
easy modification to the proof term Fac of section 5.1 yields a term 


Fac’ : | eases’ Hieen Negron RS H(vf {R A (J f) we i} fac (j f) f {R A fT aS i!}) 


expressing the correctness of fac even if its second argument interferes with its first. 


6 Conclusions and Future Work 


We have made a simple syntactic adjustment to Hoare Logic and demonstrated how its repre- 
sentation in a meta-logic gives us a more powerful programming logic for free. Our encoding 
improves upon those in the literature in both elegance and power, avoiding judgments concern- 
ing non-interference and the restriction to a fixed finite collection of program variables. We have, 
with relative ease, added extensions to the signature which handle local variables, data types, and 
inductively-derived admissible rules, further evidence that our approach is the right one. A ma- 
chine implementation of the logic has been directly obtained from the representation and used to 
check the examples of this paper. Thus we have reaped the philosophical, theoretical, and practical 
benefits of formalization mentioned in the introduction. 

Mason suggests in {7, pg. 12] that the LF is to blame for the complexities of formalizing Hoare 
Logic, as it does not have a direct means to represent call-by-value substitution. The work pre- 
sented here is intended to indicate that the fault lies in Hoare Logic itself: plain Hoare Logic does 
not respect substitution, and even the ornate form of it given in our calculus QHL, does not ad- 
mit contraction of active identifiers, a non-standard structural rule which conflicts with those of 
the LF. U. S. Reddy! has proposed the possibility of a dual solution to our affine quantifier Y: 
formalizing Hoare Logic in an “affine LF” which disallows contraction at the meta-level, requiring 
the introduction of a classical quantifier C to handle passive identifier occurrences. Perhaps the 
cleanest encoding could be obtained in a version of LF which employed both kinds of dependent 
product as primitive, evoking the type regimen of Syntactic Control of Interference in [9]. 

Part of the “essence of Algol” [12] is the simplicity of its definition, which is essentially the 
inclusion of commands as a base type in a typed A-calculus. It seems reasonable, therefore, to 
approach the design of a programming logic for Algol in the same way, namely as the inclusion of 
Hoare formulas as a basic judgment form in a logical framework consisting of a typed \-calculus. 
We believe that our work is the first step towards such a logic. Two avenues of research in this vein 
present themselves: 


1. We are investigating the consequences of internalizing phrase types, type constructors, and 
the notion of computation, and extending the programming language to include conditionals 
and recursion at arbitrary phrase types. It appears that the resulting system will be a sound 
logic for Algol which is cleaner than, although non-trivially related to, Specification Logic. 
See the appendix for a brief discussion. This approach actually reveals yet another benefit of 
formalization: we can concisely specify a new logic in the meta-logic, allowing the theory of 
the meta-logic to generate the object logic we want. 


2. Strengthening the type system of the LF itself will lead to a correspondingly stronger pro- 
gramming logic. For example, there is a published formulation of LF which include pairing [4] 
which is believed to preserve its good properties. The closer the type theory of the meta-logic 


1 Private communication. 
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matches the type theory of Algol, the more attractive our formalization will become as a basis 
for a programming logic. 

An additional challenge is presented in light of an unpublished paper of M. Miculan [8]. Standard 
encodings of first-order logic in LF are adequate for the consequence relation of truth rather than 
validity [2], yet the rules given for Hoare Logic are sound only with respect to validity. In particular, 
there exist proofs from assumptions in Hoare Logic which have no counterpart in the LF encoding. 
This fact does not contradict our adequacy theorem, which is stated with respect to the empty 
context only; however, we would like to incorporate the side conditions introduced in [8] to broaden 
the semantic adequacy of the encoding. 
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A Towards a Signature for Algol 


The rules of the signature L7,, modulo some syntactic dressing, can become the nucleus of a logic 
for full Idealized Algol. The only significant change we make is to internalize phrase types and the 
notion of computation, so that recursion can be encompassed. 


A.1 Phrase Types 


To encode the syntax of Algol we must internalize its type constructors. The syntax of the new 
signature, eyes is shown in Table 5. 

For simplicity, we have removed boolean expressions (quantifier-free assertions) from commands 
altogether. Instead we insist that there be a designated constant expression 0 and define the 
conditional if0 to test its first argument for equality to 0. (The theory T can internalize the 
boolean connectives and predicate symbols as function symbols so that no expressiveness is lost.) 
Thus recursively-defined expressions can appear in conditionals, but assertions cannot be recursively 
defined. 

The new form of the conditional allows us to create “bad” variables [13]. A bad variable is a 
term of type var such that assigning value v to it and immediately dereferencing it may not yield 
v. The assignment axiom will need no modifications, however, because it only permits us to reason - 
about assignments to V-bound identifiers in a prefix, which are assumed to denote good variables 
and cannot (through substitution) be replaced by bad ones. In fact, using the assignment axiom we 
can only reason about terms of type var which compute (see below) to one of the prefix identifiers; 
other such terms, like conditional variables depending on active values, must first invoke a rule like 
IffnAx to be handled. By virtue of this soundness property, new creates only good variables. 


A.2 Judgment Forms 


Having removed assertions from commands we have no further use for QF. However, to reason about 
conditional expressions and phrases of higher type, we need another judgment form internalizing the 
notion of computation, similar to the =, of Specification Logic or the [(A, a, 6) types of Martin-Lof 
type theory: 
comp : TYPE 
> : IIr-phrtype Lie 2 COUP. 
C : comp — TYPE. 


A.3 Axioms and Inference Rules 


Most of the rules from COHL carry over almost verbatim. We also must include computation rules 
and substitution rules for allowing computationally-equivalent terms to appear interchangeably in 
judgments. The complete set of rules is shown in Table 6, and the logic PL alg is defined to be the 
set of terms generated in LF by the signature wale” 
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spec, assert, PhrType 


exp, comm 
—_, x< 


acc 


3 


>,A,V 


V,4 


1 
skip 


whileO 


new 


ug Ne -- ers games 


TYPE 
PhrType — TYPE 
PhrType 


PhrType — PhrType — PhrType 


exp — comm: PhrType 
exp X acc: PhrType 


[Is-r:pnrtype > ihc it ia) re 
Ils.r-purtype 9 X T So 


Ils.7-phrtype S ETE 


Ils.7-Purtype(2 eres bs: 
Ils.7-phrtype S pong! mata 


IIr-phrtype ies i} Sh it 
IIp-partype OXP ToT oT 


AT .Yr7 (Arr (Az .2)): IIr-purtype Ai 


assert — comm — assert — spec 
(Var — spec) — spec 


exp 


SE, 
exp — ... — xp — Exp 
exp — €xp — assert 

m 


exp — ... — exp — assert 
assert — assert — assert 
assert — assert 

(€xp — assert) — assert 


I 


exp,exp—comm 


Tv : var — exp 
comm 


ADexp.commsocGc, Cxp > Comm 
comm — comm — comm 


Nex Ac o¥se, at Adele te(cr i d)iskip) 


exp — comm — comm 
exp — (Var — comm) — comm 


Table 5: Syntax of Uij,. 


Ll} 


[c € T] 


[f eT, arf) =n] 


[r € T,ar(r) = m] 


AsgnAx; 1 : [I p-exp—assert Ileaxp—axp 


: [ieaseers H({P} skip Baty, 
: Ll p-qrassert H({P}.Lcomm4@}) 


SkipAxg 
AbortAxg 
SeqRuley 
IfRule, 


ConRuley 


NewRule, ; 


Exch : 
YIntroAx : 
YIntroUn : 

YIntroBin : 


ReflAx 


ProjRAx 


IfProdAx 


RecAx : 


FixInd 


Subste 
Substy 


Subst x 


: Theo reassert Il. ¢:comm 


: IIp. ,P,Q,Q':assert ll comm 


: IIr-partype Teer [lf ane C(t =r t’) se C( f t’) aa 
: IIr-purtype Tee fipradeen C(t =p t’) amd T(f t’) er ig t) 
: II7-pnetype Tee i eee C(t > t’) ae H(f t’) ce H(f t) 


Hv2{PGct)} easitcidPiat}) 


H({P}c{Q}) — H({Q}d{R}) — H({P}c; d{R}) 


: Tl eoiassert Il.-axp I]. a-comm 


H({P Ae = 0}c{Q}) + H({P Ae £0} d {Q}) — H({P} if comm €¢ 4 {Q}) 
T(P’ > P)+T(Q>@)— 
H({P}¢{Q}) — H({P’}¢{Q'}) 


. [lporsscrt |B ie rer mee (eee. 


H(¥r{PAct =e}cxr{Q}) — H({P}newec{Q}) 
Il} .sar—var—spec H(VaVy f cy) + H(WyVe f zy) 
TT) var—-spec hlevanet\) ermen ry 
T1},g:vaF—spec (lever H(f 2) + H(g2)) — 


I] }.9,n:vaF—spec 


(Tlevar H(f 2) + H(g 2) — H(h2)) — 


(H(v f) — H(v g)) 


(H(V f) + H(¥ 9) — H(v A) 


> [p-phetype [a7 C(4 5, 2) 
ExpAx : 
ApAx : 
BotFnAx : 
BotProdAx : 
ProjLAx : 


Teva T(t =H) C(t 3, ¢”) 

Is,7-phetype [1,37 Tas C(((As.r f) aps7 2) Sp (f @)) 
IIs.7-purtype C(Lso7 3 5_ 7 Asr (Az. Lr)) 
I1s.r-partype C(Lsxr S5y7 (1s; ir)sr) 

IIs.7-phrtype Tas [hs C((t5-7 (a,b), 7) >, 2) 


: IIs.7-pnrtype Mice: IL..7 C(t 7 (a, b)5 7) =r b) 
IfFnAx : 


IIs.7-phrtype Ile-axp ‘exp = 
C((if0s_r e f 9) Sp (Asr (Ax .ifr e(f apsr t) (9 apsr 2)))) 


: ITs, T:PhrType Il.-axp ‘exp Ide qiSXT 


C((if0s.7r e pq) FF 5KT (ifs e€ (TS.r P) an q),if0r e (Tor P) (TS 7 1). ) 
ITr. PhrType IL FarC(Yr f) = Sy apr rT (Yr f))) 


: Iz. PhrType IL :‘T—spec Il. 


H(f Lr) — (Iz H(f t) + H(s (p aprr t))) > HUE (Yr p)) 


C(f t) 


Table 6: Axioms and Rules of Dij,. 
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An Imperative Object Calculus 


Basic Typing and Soundness 


Martin Abadi and Luca Cardelli 


Digital Equipment Corporation, Systems Research Center 


Abstract 

We develop an imperative calculus of objects that is both tiny and expressive. Our calculus 
provides a minimal setting in which to study the operational semantics and the typing rules 
of object-oriented languages. We prove type soundness using a simple subject-reduction 


approach. 


1. Introduction 


Procedural languages are generally well-understood; their constructs are by now standard, and 
their formal underpinnings are solid. The fundamental features of procedural languages have been 
distilled into formalisms that prove useful in identifying and explaining issues of implementation, 
static analysis, semantics, and verification. 

An analogous understanding has not yet emerged in object-oriented programming. There is no 
widespread agreement on the choice of basic constructs and on their properties. Consequently, 
practical object-oriented languages support many features and programming techniques, often with 
little concern for orthogonality. 

With the aim of clarifying the fundamental features of object-oriented languages, we introduce 
atiny but expressive imperative calculus. The calculus comprises objects, method invocation, 
method update, object cloning, and local definitions. In a quest for minimality, we take objects to be 
just collections of methods. Fields are important too, but they can be seen as a derived concept; for 
example a field can be viewed as a method that does not use its self parameter. 

When fields and methods are identified it is trivial to convert one into the other, conceptually 
turning passive data into active computation and vice versa. The hiding of fields from public view 
has been widely advocated as a means of concealing representation choices, and thereby allowing 
flexibility in implementation. Identifying fields with methods confers much of the same flexibility, 
by eliminating fields. 

The unification of fields with methods has also the advantage of simplicity. Both objects and 
object operations assume a uniform structure. In contrast, the separation of fields from methods 
induces a corresponding separation of object operations, and leads to the implicit or explicit split- 
ting of objects into two components. Unifying fields with methods gives more compact and there- 
fore more elegant calculi. 

This unification, however, has one debatable consequence. The natural operation on methods is 
method invocation, and the natural operations on fields are field selection and field update. By uni- 
fying fields with methods, we can collapse field selection and method invocation into a single op- 
eration. To complete the unification, though, we are forced to generalize field update to method up- 
date. 
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The reliance on method update is one of the most unusual aspects of our formal treatment: this 
operation is not normally found in programming languages. However, method update can be seen 
as a form of dynamic inheritance [25] which is a feature found in object-based languages [7] but 
not yet in class-based languages [6]. Like other forms of dynamic inheritance, method update 
supports the dynamic modification of object behavior allowing objects, in a sense, to change their 
class dynamically. Thus, method update gives us an edge in modeling object-based constructions, 
in addition to allowing us to model the more traditional class-based constructions where fields and 
methods are sharply separated. 

A further justification for method update can be found in the desire to tame dynamic inheri- 
tance. Dynamic inheritance has potentially unpredictable effects, due to the updating of shared state. 
These concerns have led to the search for better-behaved, restricted, dynamic inheritance mecha- 
nisms [23]. Method update is one of these better-behayed mechanisms, especially in the absence of 
delegation, as in our calculus. Method update is statically typable, and can be used to emulate the 
mode-switching applications of dynamic inheritance [13]. With method update we avoid some dan- 
gerous aspects of dynamic inheritance [14, 23], while maintaining its dynamic specialization aspects 
originally advocated by the Treaty of Orlando [22]. 

In this paper, we study an untyped calculus (section 2), and then we present a type structure for 
it (section 3). The only type constructor is one for object types: an object type is a list of method 
names and method result types. A subtyping relation between object types supports object sub- 
sumption, which allows an object to be used where an object with fewer methods is expected. We 
prove the consistency of our rules using a subject-reduction approach (section 4). Our technique is 
an extension of Harper’s [16], using closures and stacks instead of formal substitutions. This ap- 
proach yields a manageable proof for a realistic implementation strategy. 

Elsewhere we have considered functional calculi [2-4]. The main novelty here is the treatment 
of imperative features, with corresponding proof techniques. In further work [5] we treat second-or- 
der type structures (with Self types) for an imperative calculus. 

A few other object formalisms have been defined and studied. Many of these rely on purely 
functional models, with an emphasis on types [1, 8, 10, 12, 17, 19-21, 26]. Others deal with 
imperative features in the context of concurrency; see for example [28]. The works most closely 
related to ours are that of Eifrig et al. on LOOP [15] and that of Bruce and van Gent on TOIL [9]. 
LOOP and TOIL are typed, imperative, object-oriented languages with procedures, objects, and 
classes. Both take procedures, objects, and classes as primitive, with fairly complex rules; they also 
distinguish methods from fields. LOOP is translated into a somewhat simpler calculus, which 
includes record, function, reference, recursive, and F-bounded types. Our calculus is centered 
entirely on objects: procedures and classes can be defined from them. The collections of programs 
that can be written and typed in these formalisms are different. In spite of this, we all share the goal 
of modeling imperative object-oriented languages by precise semantic structures and sound type 
systems. 


2. An Untyped Imperative Calculus 


We begin with the syntax of an untyped imperative calculus. The initial syntax is minimal, but 
in sections 2.2 and 2.3 we show how to express convenient constructs such as fields and proce- 
dures. We omit how to encode basic data types, control structures, and classes, which can be treated 
much as in [4]. In section 2.5 we give an operational semantics. 
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2.1 Syntax 


Syntax of the imp-¢ calculus 


Ct i eet ae tir hei ih shoes feel mee eE Wie oh. wise vil Sa\icli abou saree | 


a,b ::= term 
x variable 
[li=o(xi)b; 11-9] object (1; distinct) 
al method invocation 
a.le¢(x)b method update 
clone(a) cloning 
letx =ainb let | 
|e ee te Ee ET SS ee 


An object is a collection of components 1;=¢(x;)b;, for distinct labels 1, and associated methods 
¢(x;)b;; the order of these components does not matter, even for our deterministic operational se- 
mantics. The letter ¢ (sigma) is used as a binder for the self parameter of a method; ¢(x)b is a method 
with self parameter x, to be bound to the host object, and body b. 

A method invocation 0.1 results in the evaluation of the body of the method named |, with o 
bound to the self parameter. 

A method update o.l=¢(y)b replaces the method named | with ¢(y)b in o, and returns the modi- 
fied object. 

A cloning operation clone(o) produces a new object with the same labels as 0, with each com- 


ponent sharing the methods of the corresponding component of o. 
The let construct evaluates a term, binds it to a variable, and then evaluates a second term with 
that variable in scope. Sequential evaluation can be defined from let, by: 


aib 4 tet x=a in b, 


for x ¢ FV(b). 


2.2 Fields 


In our imp-¢ calculus, every component of an object contains a method. However, we can en- 
code fields with eagerly evaluated contents by using the let construct. We write [l,=b, ‘€!--, 
l=¢(x;)b; €'-™] for an object where |;=b; are fields and 1;=<(x;)b; are methods. We also write a.l:=b for 
field update, and a.l, as before, for field selection. We abbreviate: 


Encoding of fields 


(1=b, '!-9, =<(x;)b; Jet] for y; ¢ FV(b; '*!-", b; J€!-™), y; distinct, ie0..n 
2 let y;=b, in... let y,=b, in [l=¢(Yo)yi €!-%, =G(xq)b, 1!) 
let y;=a in let y2=b in y,.l=<¢(yo)y2 for y, ¢ FV(b), y; distinct, i€0..2 


a.l:=b 


i> 


The semantics of an object with fields may depend on the order of its components, because of side- 
effects in computing contents of fields. The encoding specifies an evaluation order. 

By an update, a method can be changed into a field and vice versa. Thus, we use somewhat in- 
terchangeably the names selection and invocation. 
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2.3 Procedures 


The imp-¢ calculus is so minimal that it does not include procedures, but these can be ex- 
pressed too. We begin by considering informally a call-by-value A-calculus with side-effects, imp-A, 
that includes abstraction, application, and assignment to A-bound variables. For example, assuming 
arithmetic primitives, (A(x) x:=x+1; x)(3) is an imp-A term yielding 4. We translate imp-A into imp-s. 


Translation of procedures 


(x), 2 p(x) if xedom(p), and x otherwise 
(A(x)b), = [arg ban ¢(x)x.arg, val are G(X) Cb) 5 (xex.arg) 
(b(a)),  * (clone((b),).arg:=(a),).val 


(x:=a), 2 X.arg:=(a), 


In the translation, an environment p maps each variable x either to x.arg if x is A-bound, or to x if x 
is a free variable. A A-abstraction is translated to an object with an arg component, for storing the 
argument, and a val method, for executing the body. The arg component is initially set to a diver- 
gent method, and is filled with an argument upon procedure call. A call activates the val method that 
can then access the argument through self as x.arg. An assignment x:=a updates x.arg, where the ar- 
gument is stored (assuming that x is A-bound). A procedure needs to be cloned when it is called; the 
clone provides a fresh location in which to store the argument of the call, preventing interference 
with other calls of the same procedure. Such interference would derail recursive invocations. (This 
encoding has similarities with the mechanism of method activation in the Self language [25].) 


2.4 A Small Example 


We give a trivial example as a notation drill. We use fields, procedures, and basic data types in 
defining a memory cell with get, set, and dup (duplicate) components: 


let m = [get =0, set = ¢(self) A(b) self.get:=b, dup = ¢(self) clone(self)] 
in m.set(1); m.get yields 1 


This cell can be used as a prototype for building cells, which can then be customized by method 
update. For example, we may create a cell that accepts only non-negative integers through the set 
method: 


let m = [get = 0, set = ¢(self) A(b) self.get:=b, dup = c(self) clone(self)] 
in m.dup.set = ¢(self) A(b) if b<O then self.get:=0 else self.get:=b 


2.5 Operational Semantics 


We now give an operational semantics that relates terms to results in a global store. Object 
terms reduce to results consisting of sequences of store locations, one location for each object com- 
ponent. In order to stay close to standard implementation techniques, we avoid using formal substi- 
tutions during reduction. We describe a semantics based on stacks and closures. A stack § associ- 
ates variables with results; a closure (¢(x)b,.5) is a pair of a method together with a stack that is used 
for the reduction of the method body. A store maps locations to method closures; we write stores in 
the form 1;->(¢(x;)b;,5) '€'-"; we write 6.1m for the result of putting m in the 1 location of o. 

The operational semantics is expressed in terms of a relation that relates a store o, a stack S, a 
term b, a result v, and another store o’. This relation is written 6-54 b > v-o”’, and it means that 
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with the store o and the stack 5, the term b reduces to a result v, yielding an updated store o’. The 
stack does not change. The operational semantics is presented formally as follows. 


Operational semantics 


l store location é(e.g., an integer) 
Viegas) |[1,e2, i649] result (1, distinct) 
Os 4>(6(x,)b;,.§) i! store (1; distinct) 
S ( sto4 xprv, jel stack (x; distinct) 


Well-formed store judgment: oF o 
(Store ¢) (Store 1) | 
Oo-SEo t.¢dom(o) 


Bro G, >(¢(x)b,.5) Fo 


Well-formed stack judgment: o+-St o 


(Stack g) (Stack x) 
ple aay 2 es ots SOUND) Ly Xf Som(S) UI, ' distinct. Vieln 
Ogro G+ S, x>[]=1, €!-2] k o 


Term reduction judgment: 0-SFa~>v-o’ 


(Red x) } (Red Object) 

20 -ar*V,5 1° O-SFo 1u¢dom(o) t,distinct Viel..n 
B+ S4X*V,S"E XK Me ve Oe SF []=6(x4)b; 1-7] > [= '*!-] + (6, ty->(G(K))B,S) €!-*) 
(Red Select) 


O-SF a> [lst '*!*]-0" — (4) =(6(x))b;,5’) x; ¢ dom(S’) — jel..n 
Ge ody Xi SLL <! 8] I by > veo" 
OSE al; > veo” 
(Red Update) 
o-St a ~> [l=1,'€!-"]-0’ = jeél..n 4edom(o’) 
OSE aliec(x)b > []j=t; €!-7] « 0 .1454(G(x)b,9) 
(Red Clone) 
O-SF a ~> [l= €!-"]-0’ t.€dom(o’) v,¢dom(o’) 1’, distinct Viel..n 


6-SF clone(a) > [l=v’; '€!-"] - (0’, v0" (1) i€!-") 


(Red Let) 
O-SFa~v’-o 0'«5, xv’ Eb > v’.0” 


O- St letx =ainb ~ v’.o” 


A variable reduces to the result it denotes in the current stack. An object reduces to a result consist- 
ing of a fresh collection of locations; the store is extended to associate method closures to those lo- 
cations. A selection operation reduces its object to a result, and activates the appropriate method 
closure. An update operation reduces its object to a result, and updates the appropriate store loca- 
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tion with a new method closure. A clone operation reduces its object to a result; then it allocates a 
fresh collection of locations that are associated to the existing method closures from the object. A let 
construct reduces to the result of reducing its body in a stack extended with the bound variable and 
the result of its associated term. 

We illustrate reduction with two examples. The first one is a simple terminating reduction for 
the term [1 = ¢(x)[]].1. The following represents a (partial) derivation tree, with bracketed subtrees: 


BBE [l=o(x)[]] ~> [=0]-(O-(¢(x)[],2)) by (Red Object) 
(O>(¢(x)[],))-(x->01=0]) F 1] ~> 0-(0r>(¢(x)],9)) by (Red Object) 
B-Db [l=¢(x)[]]-1 > (]-CO-(¢(x)[],)) by (Red Select) 


We illustrate method overriding, and the creation of loops through the store, by evaluating the term 
[1 = ¢(x) x.l=¢(y)x].1. 


let Op = OF>(C(x)x.l=¢(y)x, @) and 6, = Or(¢(y)x, (x->[l=0])) 


BB t [l=c¢(x)x.l=¢(y)x] ~~ [1=0]-dp by (Red Object) 

[ ops(x-[1=0]) F x > [1=0]-05 by (Red x) 

Oo-(x+>[1=0]) F x.lec(y)x > [l=0]-0, by (Red Update) 
BB b [l=c(x)x.le¢(y)x].1 ~> [l=0]-0, by (Red Select) 


The store 6, contains a loop, because it maps the index 0 to a closure that binds the variable x to a 
value that contains index 0. Hence, an attempt to read out the result of (l=¢(x)x.l=¢(y)x].1 by 
“inlining” the store and stack mappings would produce the infinite term [l=¢(y)[l=¢(y)[l=<¢(y)...]]]. 

The potential for creating loops in the store is characteristic of imperative semantics. Loops in 
the store complicate reasoning about programs and, as we see in the next chapter, they also demand 
special attention in the treatment of type soundness. 


3. Typing 


We define a type system for the untyped calculus of section 2, and give a typed example. 


3.1 Typing Rules 


The typing rules for objects are the same ones we would have for a functional semantics. They 
are in fact a superset of those of [4], except that terms do not contain type annotations (to match our 
untyped operational semantics). 


Typing rules 


_Well-formed environment and type judgments: EF o, EFA 


(Env g) (Env x) (Type Object) (1; distinct) 
EFA xédom(E) EFB, Viel..n 
E,x:Ak o EF [],:B; ‘¢!-"] 


Gro 
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Subtyping judgment: EF A<:B 


(Sub Refl) (Sub Trans) (Sub Object) (1; distinct) 
EFA EFA<:B EFB<:C EFB, Viel..n+m 
EFA<:A EFA C EF [],:B; i€!-2+™] <: [1;:B; i€!--9] 


a nee ee ee ee ha a eke ae Sek be ea 
Value typing judgment: EFa:A 


(Val Subsumption) (Val x) (Val Object) (where A=[];:B; i€!-"}) 
ErPavA LT aAans BE’ xcA,E P'S EB, x; Ar 6) B,” Vjel..o 
EFa:B E’X:A,E”F x:A EF [l=<(x;)b; '€!-2]: A 

(Val Select) (Val Update) (where A=[];:B; '€!-"]) 
Bae Be}s|yjeion Eee to bee je ln | 

EF al: B; EF alje¢(x)b: A 
(Val Clone) (where A=[I,:B; ‘€!-]) (Val Let) 

EkFa:A EijaiA, ~EaxiA &.baB 


EF clone(a): A EF letx=ainb:B 


The first two groups of rules concern typing environments, types, and the subtyping relation. An ob- 
ject type is a collection of method names and associated method result types. A longer object type 
is a subtype of a shorter one, without variation in the common type components. The final group 
concerns typing of values. There is one rule for each construct in the calculus; in addition, a sub- 
sumption rule connects value typing with subtyping judgments. 


3.2 A Typed Example 


This section illustrates how to type a simple imperative example: movable points. In this ex- 
ample we rely on fields and procedures, as encoded in section 2. The encoding of procedures type- 
checks with A-B translated as [arg:A, val:B]. 

Trivial as it may seem, the example of movable points has been a notorious source of difficul- 
ties in functional settings (see [4]). These difficulties have resulted in the use of sophisticated type 
theories. In an imperative setting, however, some of these difficulties can be avoided altogether. 

Consider one-dimensional and two-dimensional points, with coordinate fields (x and y) and 
methods that modify these fields (mv_x and mv_y). The coordinates are integers. We assume that 
integers and reals are available, perhaps through an encoding. For example, the origin points are: 


pi = [x =0, mv_x =¢(s) A(dx) s.x:=s.x+dx] 
p2. =.. [x =0, 
y =0, 


mv_x = ¢(s) A(dx) s.x:=s.x+dx, 
mv_y = ¢(s) A(dy) s.y:=s.y+dy] 
In the type system of section 3.1, p; and p2 can be given the types: 


P, 
P2 


[x:Int, mv_x:Int[]] 


I> I> 


([x,y:Int, mv_x,mv_y:Int—>[]] 
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where P2 is a subtype of P;. This result type [] is obtained by subsumption. The imperative opera- 
tional semantics produces the desired effect of moving a point, without requiring any particular re- 
sult type for move methods. In contrast, in a functional framework an informative result type is nec- 
essary. 

Imperatively, there is no loss of type information when moving a point. For example, suppose 
that f is defined with one-dimensional points in mind, with the type P;—>[], and normz is defined for 
two-dimensional points, with the type P2—Real: 


f:P,>[] = A(p) p.mv_x(1) 
norm: P>—>Real = A(p) sqrt(p.x*2 + p.y*2) 


Since P} is a subtype of P), f(p2) is a legal call for p2:P2. Therefore, the following code typechecks 
and, as expected, returns 1: 


f(p2); norm2(p2) 


Thus, we have applied a P,; procedure to a P2 point, and after this we are still able to use the point as 
a member of P32. In contrast, in a functional setting we may try to write norm2(f(p2)), which is not 
well-typed if f:P,;—>({]. 

Even in an imperative setting, however, it is common to define methods that produce new ob- 
jects, as opposed to modifying existing ones. If mv_x is to return a new object, one must declare it 
with result type P; or P2, to take advantage of any change to the x coordinate. One may try to rede- 
fine P; and P2 as recursive types (for example, P, 2 w(X)[x:Int, mv_x:Int—>X]), but then P) is not a 
subtype of P;. With this definition, all the typing difficulties common in functional settings resurface. 


4. Soundness 


We show the type soundness of our operational semantics, using an approach similar to subject 
reduction. We build on the techniques developed by Tofte, Wright and Felleisen, Leroy, and Harper 
[16, 18, 24, 27]. Our proof technique is an extension of Harper’s, in that we deal with closures and 
stacks and thus avoid introducing locations into the term language. 

The typing of results with respect to stores is delicate. We would not be able to determine the 
type of a result by examining its substructures recursively, including the ones accessed through the 
store, because stores may contain loops. Store types, introduced below, allow us to type results in- 
dependently of particular stores. This is possible because type-sound computations do not store re- 
sults of different types in the same location. Next we formalize store types and other notions neces- 
sary for the proof of soundness. 

A store type 2 associates a method type to each store location. A method type has the form 
[1;:B; '‘<'-"]=>B;, where [I,:B; ‘«!-"] is the type of self, and B; is the result type, for jé1..n. The statement 
of soundness relies on a new judgment, result typing: £ F v : A. This means that the result v has type 
A with respect to the store type 2. The locations contained in v are assigned types in . 

To connect stores and store types, we use a judgment 2 F o. Checking this judgment reduces 
to checking that the contents of every store location has the type determined by the store type for 
that location. Since locations contain closures and store types contain method types, we need to 
determine when a closure has a method type. For this, it is sufficient to check that a stack is compat- 
ible with an environment; the environment is then used to type the method. We write ZF 5: E to 
mean that the stack § is compatible with the environment E in £. Now, since stacks contain results 
and environments contain types, we can define ZF 5S: E via the result typing judgment, which we 
have already discussed. The rule for store typing deals with each closure with respect to the whole 
store, accounting for cycles in the store. 


26 


Store typing rules 


: 
method type (jél..n) 


M::= — [];:B; '*!-"]=>B,; 

Di. 1-eM, 1-8 store type (1; distinct) 

2.) 2 0: Byitt-2] if X(t) = [];:B, '*!-"]=B,; 

x(t) 4 B; if X(t) = (1;:B; iel..n—>B, 


Well-formed method type and store type judgments: - Me Meth, ZF o 


(Method Type) (Store Type) 
jéel..n EM,e Meth 1,distinct Vie l..n 
F (1,:B; iel..n)—>B; € Meth LM; i€l.n Eo 


Result typing judgment: TF v:A 


(Result Object) 
LFo 2,() =0;:2,0,) ©") Vie l..o 


DE [hay ita) : [:Z,(1,) ita] 


Stack typing judgment: ZES:E 


(Stack g Typing) (Stack x Typing) 
XZFo XES:E ZF f=, '€'-"]: A x ¢ dom(E) 


Store typing judgment: XFo 


(Store Typing) 
XE & 5 E; E,, X21 (1) im b; - ©,(1;) Vie l.n 
Le ueH(c(x bs) elo 


We say that 2’ is an extension of & (and write £’ > LX) iff dom(Z) c dom(’) and for all 
vedom(Z), 2’(t) = X(1). 


Lemma 4-1 
If 2F $: Eand 2’ F o with 2’ > Y, then 2’ EF S:E. 
im 4 


If a term has a type, and the term reduces to a result in a store, then the result can be assigned 
that type in that store: 


Soundness Theorem 
If EFa:A a o-Stka~veot aA LEO A dom(o)=dom(Z) A LE S:E 
then there exist a type Af and a store type Lt such that: 
Lt>zt a LTtEot a dom(ot)=dom(Zt) A LtEv: At a At< A. 


Proof 
By induction on the derivation of 6-5k a > v-ot. 
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Case (Red x) 

6 + $’,x->[]=1, €!-2],57F © 

(apc Sx (]=4, i€l.n} 7b xv =t, i€l..n] Ye} 
By hypothesis EF x: A a ZFo A dom(o)=dom(Z) a ZF $’,x->[]=1; *!-"],5” : E. Because of 
Et x: A, we must have E = E’,x:A‘,E” for some A*<:A. 
Now, LF $’,x->[l=1, €!-"],5” : E must have been derived via several applications of (Stack x 
Typing) from, among others, 2 F [l,=1; ‘€!-"] : Af. 
Take £t = £. We conclude L*F o a dom(o)=dom(2*) A Xt EF [l=1, ©"): ATA At <: A. 


Case (Red Object) 

O-SFo 1u,¢dom(c) 1, distinct Viel..n 

Oe SE [l=o(x)b; *'-7] > Hist €!-*] - (6, y>(G(xi)b, S11). 
By hypothesis EF [lj=<(x,)b €!-"]: A A ZEo a dom(o)=dom(Z) A LF S: E. Because of EF 
[l,=<(x,)b; €!-"] : A, we must have EF [lj=<(x;)b; ‘€!-] : []j:B; *!-2] by (Val Object), for some 
[1,:B; ‘€!-"] <: A. Take At = [];:B; ‘€!-"]. 
Take £* = £, 1+>(AT=B)) Je!" ; by (Store Type) we have Z*F o, because the ,¢dom(o), and 
hence u,¢dom(Z), and because F A'=>B; € Meth for jel..n. 


(1) Since <7 is an extension of £, by Lemma 4-1 we also have Z£*F §: E. Since EF 
(];=<¢(x;)b; ‘€!-"] : At, we must have E, x;:ATF b; : B;, that is, E, x,:2*,(i,) F b; : 27,(4). 

(2) We have that o has the shape €,'>(¢(x;,)b;,,.5,) K€!-™. Now, 2 F o must come from the (Store 
Typing) rule, with ZF 5: E, and E,, x,:2)(€) F by : 2,(€&,). By Lemma 4-1, Z*F 5, : E; 
moreover E,, X,:27)(€,) F b, : £(€,), because £1(€,)=Z(E,) for k € 1..m since dom(o) = 
dom(Z) = {€, *€!-™} and Lt extends =. 


By (1) and (2), via the (Store Typing) rule, we have £* F (6, 1,+>(¢(x;)b;,.5) €!-"). Since Z* F o and 
Lt =, >(AT=B,) Je!-7, by the (Result Object) rule, we have Zt F [Ij=1, '€!-"] : A’. 

We conclude that Lt > Z A LTE (6, U+>(6(x;)b;,9) *€!-") A dom(o, t;>(¢(x;)b;,.5) €!-")=dom(Z") a 
LTE [l= i!) : AT A ATK A. 


Case (Red Select) 

O-SF a> [l= '!-"]-0? = (4) =(¢(x;)b;,5’) x; ¢ dom(S’)— jel..n 

oO” + S’, X>[]=1 *!-"] Fb - v0” 

O-SF al; > veo”. 
By hypothesis EF al}: A A LEO A dom(o)=dom(Z) A LE S$: E. Since EF al; : A, we must 
have EF a: [I;:B; ...], for some [1;:B; ...] with B; <: A. 
By the first induction hypothesis: : 

Since EF a: []}:B; ...] A o-SF a» [l=1, '€!-"]-0” a ZF o A dom(o)=dom(Z) a TF S: E, 

there exist a type A’ and a store type 2’ such that: 

Ye Xa LEO a dom(o’)=dom(Z’) a 2’ F [l= '€!-"] : A’? A A’ <: [1}:B; ...]. 
Since 0’ (1t;)=(¢(x;)b;,5’), the judgment £’ F o’ must come via (Store Typing) from =’ F $’: E, 
and E,, x;:2",(1;) F b; : £’2(1;) for some E;. Since L’ F [I=1; €!-"] : A’ must come from (Result Ob- 
ject), we have A’ = [I,:273(1)) €!-"] = £",(1,). Since A’ <: [1;:B; ...], we have Z’,(1;) = B;. Then, from 
Ej, xj:2" (tj) F bj : £°2(t,) we obtain E,, x;:A’ F b; : B;. Moreover, by the (Stack x Typing) rule we 
get ES, x {l= el y Be An 
Let E’ = E,, x:A’. By the second induction hypothesis: 

Since E’F bj: B} A Oo - S’, x>[l=t, €!"] Fb; > veo” A LD’ EO’ A dom(o’)=dom(Z’) 
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AYES, x(=4 '*!-4] : EB’, 
there exist A* and &* such that: 
rt> LD a THEO” A dom(o”)=dom(Z*) a LIEV: Ata At <:B,. 
We conclude: 
xt > LX by transitivity from Lt > L’ and 2’ > &, 
+ XtEo” with dom(o”)=dom(Z"), 
» <XtEv: At with At <: A, by transitivity from A‘ <: B; and B; <: A. 
Case (Red Update) 
o-Sta> [l= i€!-4]-0’  jel.n tedom(o’) 
6+ Sk aljec(x)b ~~ [lst 1-9] - 07 44-4(G(x)b, 5). 
By hypothesis EF a.lj=¢(x)b: A A LE oO A dom(o)=dom(2) ~ Die Gu B 
Since Ef a.l;=¢(x)b : A, we must have E Fa: []:B; ...] and E; x:(]}:B; ...] b: B; for some [1;:B, ...] 
<A. 
By induction hypothesis: 
Since EF a: []j:B;...] A o-Sh a > [l=t iel.n].g” A CEO a dom(o)=dom(L) Aa LF S:E, 
there exist a type At and a store type £* such that: 
Lie La LTtEO’ A dom(o’)=dom(Z') a ZTE [l=1 4]: ATA AT <: [1;:B; ...]. 
By assumption t,¢dom(o’), hence edom(Z*). But Zt F [l=1; '*!-"] : AT must have been derived 
via (Result Object) from 2*,(1;) = [1}:2*,(1,) *!-"] = Af for all i € 1..n. Hence, since Af <: [];:B; ...], 
we have r*(1)) = Bj. Take of = 0” .1<-4(¢(x)b,.5). 
(1) We have 2tF 5: E by Lemma 4-1. We also have E, x:A‘F b : B; by a bound change lemma 
(from E, x:[]}:B; ...]/ b : B; and At <: []}:B; ...]), that is E, x:2",(,) F b : Z*,(u)). 
(2) Since Xt Fo’ must come from (Store Typing), o”’ has the shape &,>(¢(X;,)b,,.5,) Ke!-™, and for 
all k such that €,#1; and for some E, we have 'F 5, : Ey, and Ey, x4:27)(&) F by : £72(€,). 
Then by (1) and (2) we have Zt F 0” .1;<4(¢(x)b,5), by the (Store Typing) rule. 
We conclude £* > © a LE ot A STE [l= €!-"]): Af and At <: A by transitivity from At <: 
(1,:B; ...] and [1):B; ...] <: A. 
Case (Red Clone) 
O-Ska~ [l= '€'-"]-o’ t,€dom(o’). v,¢dom(o’) 1, distinct Viel..n 
O° Sk clone(a) ve (l=; i€l..n} ° (o’, U0’ (1;) iel..n). 
By hypothesis EF clone(a): A A LEO a dom(o)=dom(Z) A LF S$: E. Since EF clone(a) : A, 
we must have EF a: A (possibly via subsumption). 
By the induction hypothesis: 
Since EFa:A A Oe Sk a~ [l= €!-"].0? A DEG a dom(o)=dom(Z) A LES: E, 
there exist a type At and a store type 2’ such that: 
2’ > ZA LY FO’ a dom(o’)=dom(2’) a X’ F [l=t €!-9]: ATA At<: A. 
Let £7=(2’, vj+->2’(1,) €!-") and of S(0’, v0" (1,) €!-"). We have Lt F o by (Store Type) because 
vu’, € dom(o’)=dom(Z’), u’; are all distinct, and L’ F o is a prerequisite of L’ Fo’. 
We conclude: 
» ATCA. 
* Liem, d, because 2’ > D> and Xt > L?. 
dom(ot)=dom(Z*), by construction and dom(o’ )=dom(Z’). 
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- Z=tKo%. Since L’ Fo’ must come from (Store Typing), o” has the shape &'>(¢(X;,)b,,.5) Kel, 
and for all kel..m and for some E, we have 2’ F 5, : E, and Ey, x,:2’)(€) F by : 2’2(€&). Then 
also E,, X,:2*(€,) F b, : Z*,(€,), and by Lemma 4-1 ZF 5$, : E,. Let f:1..n.—1..m be €'.1, so that 
for all i€1..n, U=€_q). We have Ej), X42’ (Eq) F Deg : D’2(Eg@) for i€1..n, so Egg, Xgay:X" (4) F 
bey : D2(t;). Moreover, since £’(1,)=Z*(v’;), we have Egiy, Xfiy:27 (vj) F ei) : Z*2(v’;). The result 
follows by (Store Typing) from Z*F 5, : Ex, and Zt F Sri) : Egy, and Ey, xX_:27)(€,) F by : £7p(€,) 
and Egy, X¢qy:2" (0) F bey : Z*2(v’j), for ke1..m and iel..n. 

- <OtF [l=v’, €!-2]) : At. First, 2’ F [l,=1, €!-2] : AT must come from the (Result Object) rule with 
At =’ (1) = []:2’2(t) €!-4] for iel..n, and 2’ F o. But 2*(v’;) = 2’ (1,) for iel..n. So, 27,(v’;) = 
(1,:t,(v’;) i€1-2] = At, and by (Result Object) Zt F [lj=v’; €!-7] : (1;:27,(0’;) '¢!-4). 


Case (Red Let) 
O-SEb vo’ 0's 5, Xv’ Fo VO” 


o- Sk let x=c in b ~> v0”. 
By hypothesis Ef let x=cinb: A A ZF o a dom(o)=dom(Z) A ZFS: E. Since EF let x=c 
in b: A, we must have EF c: C for some C, and E, x:C F b: A (possibly via subsumption). 


By the first induction hypothesis: 

Since Ekc:C a o-SEk¥c vo’ A LEO A dom(o)=dom(z) A LF S:E, 

there exist a type C’ and a store type ~” such that: 

Y’> La LEO’ a dom(o’)=dom(2’) a VEW: Ca C'<:C. 
By Lemma 4-1, £’ F 5: E, hence by (Stack x Typing) 2’ F 5, x->v’ : E, x:C’". From E,x:CF b: A 
by bound weakening, E, x:C'F b: A. ; 


By the second induction hypothesis: 
Since E, x:C'kb:A aA O’-S, xv’ Fb vo” RS aA dom(o’ )=dom(Z’) 
ALES, xev’:E, x:C, 
there exist a type At and a store type £* such that: 
<tt> LD’ a XtEO” a dom(o”)=dom(2") a TE Vv’: Ata AT<:A. 
We conclude that £* > = (by transitivity), £* F o” with dom(o”)=dom(Z"), and Z* F v” : At with 
A‘<:A. 


O 

Corollary 
If gFa:A and ggr&amv-o 
then there exist a type At and a store type £* such that 
XtEo and LTE Vv: Af, with AT <: A. 

O 


Therefore, if a term has a type, and the term reduces to a result in a store, then the result can be 
assigned that type in that store. That is, if a term produces a result, it does so by respecting the type 
that it had been assigned statically. 

This statement is vacuous if the term does not produce a result. This can happen either because 
reduction diverges (the rules are applicable ad infinitum), or because it gets stuck (no rule is appli- 
cable at a certain stage). 

For each term there is at most one rule whose conclusion matches the syntactic form of the 
term, and hence is potentially applicable to the term. The rule (Red x) is applicable to x unless x is 
not defined in the stack. Assuming that b reduces to v, the rule (Red Update) is applicable to 
b.1j=¢(x)c provided v has |;. The applicability of the rule (Red Select) is determined with an analo- 
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gous condition. Assuming the appropriate subterms converge, the rules (Red Object), (Red Clone), 
and (Red Let) are always applicable to terms of the corresponding forms. Examining these cases, we 
can prove that the reduction of a well-typed term in a well-typed store cannot get stuck (although it 
may diverge). 


5. Conclusions 


We view our calculus as a small kernel for object-oriented languages. (In fact, its primitives 
have been used in the Obliq distributed scripting language [11].) The calculus is not class-based, 
since classes are not built-in, nor delegation-based [25] since the method-lookup mechanism does 
not delegate invocations. However, the calculus models class-based languages well, as we show in 
[4, 5]. In delegation-based languages, traits play the role of classes. Our calculus can model traits 
just as easily as classes, along with dynamic inheritance based on traits. Interpreting delegation 
fully, though, would require significant formal complications, because of the complexity of method 
lookup in delegation. 


References 


[1] Abadi, M., Baby Modula-3 and a theory of objects. Journal of Functional Programming 
4(2), 249-283. 1994. 


[2] Abadi, M. and L. Cardelli, A semantics of object types. Proc. IEEE Symposium on Logic in 
Computer Science. 1994. 


[3] Abadi, M. and L. Cardelli, A theory of primitive objects: second-order systems. Proc. 
ESOP’94 - European Symposium on Programming. Springer-Verlag. 1994. 


[4] Abadi, M. and L. Cardelli, A theory of primitive objects: untyped and first-order systems. 
Proc. Theoretical Aspects of Computer Software. Springer-Verlag. 1994. 


[5] Abadi, M. and L. Cardelli, An imperative object calculus. Proc. TAPSOFT’95 (to appear). 
Springer-Verlag. 1995. 


[6] Birtwistle, G.M., O.-J. Dahl, B. Myhrhaug, and K. Nygaard, Simula Begin. Studentlitteratur. 
1979. 


[7] Borning, A.H., Classes versus prototypes in object-oriented languages. Proc. ACM/IEEE 
Fall Joint Computer Conference. 1986. 


[8] Bruce, K., A paradigmatic object-oriented programming language: design, static typing and 
semantics. Journal of Functional Programming 4(2), 127-206. 1994. 


[9] Bruce, K. and R. van Gent, TOIL: A new type-safe object-oriented imperative language. 
Manuscript. 1993. 


[10] Cardelli, L., Extensible records in a pure calculus of subtyping. In Theoretical Aspects of 
Object-Oriented Programming, C.A. Gunter and J.C. Mitchell, ed. MIT Press. 373-425. 1994. 


(11] Cardelli, L., Obliq: A language with distributed scope. Report n.122. Digital Equipment 
Corporation, Systems Research Center. 1994. 


[12] Cardelli, L. and J.C. Mitchell, Operations on records. Mathematical Structures in Computer 
Science 1(1), 3-48. 1991. 


it 


(13] 


[14] 


[15] 


[16] 


[17] 


[18] 


[19] 


[20] 


[21] 


[22] 


[23] 


[24] 


[25] 


[26] 


[27] 


[28] 


Chambers, C., D. Ungar, B.-W. Chang, and U. Holzle, Parents are shared parts of objects: 
inheritance and encapsulation in Self. Lisp and Symbolic Computation 4(3). 1991. 


Dony, C., J. Malenfant, and P. Cointe, Prototype-based languages: from a new taxonomy to 
constructive proposals and their validation. Proc. OOPSLA’92. 1992. 


Eifrig, J., S. Smith, V. Trifonov, and A. Zwarico, An interpretation of typed OOP in a 
language with state. Dept. of Computer Science, The Johns Hopkins University. 1993. 


Harper, R., A simplified account of polymorphic references. /nformation Processing Letters 
51(4). 1994. 

Harper, R. and B. Pierce, A record calculus based on symmetric concatenation. Proc. 18th 
Annual ACM Symposium on Principles of Programming Languages. 1991. 


Leroy, X., Polymorphic typing of an algorithmic language. Rapport de Recherche no.1778 
(Ph.D Thesis). INRIA. 1992. 


Mitchell, J.C., F. Honsell, and K. Fisher, A lambda calculus of objects and method 
specialization. Proc. 8th Annual IEEE Symposium on Logic in Computer Science. 1993. 


Pierce, B.C. and D.N. Turner, Simple type-theoretic foundations for object-oriented 
programming. Journal of Functional Programming 4(2), 207-247. 1994. 


Rémy, D., Typechecking records and variants in a natural extension of ML. Proc. 16th 
Annual ACM Symposium on Principles of Programming Languages. 1989. 


Stein, L.A., H. Lieberman, and D. Ungar, A shared view of sharing: the treaty of Orlando. In 
Object-oriented concepts, applications, and databases, W. Kim and F. Lochowsky, ed. 
Addison-Wesley. 31-48. 1988. 


Taivalsaari, A., Object-oriented programming with modes. Journal of Object Oriented 
Programming 6(3), 25-32. 1993. 


Tofte, M., Type inference for polymorphic references. /nformation and Computation 89, |- 
34. 1990. 


Ungar, D. and R.B. Smith, Self: the power of simplicity. Lisp and Symbolic Computation 4(3). 
1991. 


Wand, M., Type inference for record concatenation and multiple inheritance. Proc. 4th 
Annual IEEE Symposium on Logic in Computer Science. 1989. 


Wright, A.K. and M. Felleisen, A syntactic approach to type soundness. /nformation and 
Computation 115(1), 38-94. 1994. 


Yonezawa, A. and M. Tokoro, ed. Object-oriented concurrent programming. MIT Press. 
1987. 


32 


Lazy Computations in an Object-Oriented Language for 
Reactive Programming 


Johan Nordlander 
Department of Computing Science 
Chalmers University of Technology 

S - 412 96 Goteborg, Sweden 


Email: nordland@cs.chalmers.se 


December 22, 1994 


Abstract 


We present a model of programming which includes lazy expression evaluation as well as 
communication between parallel objects encapsulating a local state. The purpose of introducing 
objects in this model is to make explicit the context in which functional programs execute, in 
order to separate the abstract results a system computes from the interaction it maintains with 
its environment. We use the word reactive to describe this. model, which emphasizes our view 
that the utmost purpose of a computer system is to react to stimuli from the outside. 

The reactive programming model consists of a combination of object-oriented and functional 
styles, in such a way that the object-oriented level of programming has access to the functional 
world, but not vice versa. By keeping this distinction, our expression sublanguage can maintain 
the typical properties of purely functional languages: non-strict semantics, freedom of side-effects, 
etc. In this presentation, we illustrate our notion of reactive programming by means of a pro- 
gramming language, for which we give an operational semantics, as well as a couple of examples 
of typical use. 


1 Introduction 


What is the goal for introducing a notion of state in functional languages? Are we primarily interested 
in making our languages more adapted to the machine or to the programmer? 

Programming with state is generally regarded as a rather machine-oriented way of programming. 
This is especially true when we compare with functional languages, which support a high level of 
abstraction and are designed without any specific machine-architecture in mind. Thus, the motiva- 
tion for introducing state in a functional language is mostly pragmatic: it gives the programmer an 
opportunity to write more efficient code than what might otherwise be produced by the compiler. 
The challenge to the language designer is then how to encapsulate such pieces of stateful code so that 
they may be treated as genuine functions when called from the outside. In these settings, stateful 
programming is considered an alternative, but obviously less human-friendly means of expressing 
something which is still preferably thought of as a function. 

However, we consider the notion of state to be equally important when it comes to making func- 
tional languages more human-friendly. This is not a manifestation of some idea that imperative 
algorithms should be easier to grasp for beginners — in fact we think that the opposite situation 
is more likely to be true. We advocate a model of state because of a perceived limitation of the 
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functional programming paradigm: its inherent intuition that the computer is a programmable cal- 
culator, whose purpose is to deliver a result when fed with a function and some input data. However 
true this view may have been in the dawn of the computer era, users of modern personal computers 
probably view their machines more as flexible storage-devices, databases, simulators (of office desk- 
tops and cockpits), controllers (of radiators and telephone lines), etc; i.e. machines that maintain an 
interaction with their environment. In the description of such machines, we find it very unintuitive 
to focus on what result is being computed (what is really the result of an operating system?). 

In our view, a far more statisfactory model concentrates on the state of a computer system — 
how it is composed and how it reacts to various events. The argument for this view is simply 
that humans (including programmers) tend to interpret their environment (including computers) 
in terms of state and change. Files, screens, windows, etc, are arguably more easily thought of as 
unique objects with a changeable state, than as the mere representation of some primary, infinite 
expression under evaluation. On the other hand, many computing tasks involve no interesting states 
apart from their results, nor do they need to synchronize with the external world. For such tasks, 
a state model becomes equally unpleasant, since humans generally prefer to understand these tasks 
as abstract mappings. So, what we would really like is a kind of hybrid model, which uses functions 
to describe mappings, and state to capture interaction. 

In this paper, we present an attempt towards this goal, by means of a lazy functional language 
extended with concepts borrowed from object-oriented technology. As we have indicated above, 
we are not concerned with retaining the programs-as-functions paradigm of functional languages; 
instead we favour a reactive model, where a program is a dynamic collection of transiently active 
objects managing a local state. We are, however, very concerned with not destroying the main 
virtues of lazy functional languages, i.e. those virtues that permit unrestricted equational reasoning 
about expressions. Thus, in our model of programming, expression evaluation is free from side- 
effects, referentially transparent, and independent of order (assuming termination). This is achieved 
by an asymmetric combination of object-oriented and functional programming, such that the object- 
oriented level is aware of the functional world, but not vice versa. The vital properties of the reactive 
model are summarized below: 


e It is object-oriented, in the sense that it supports and enforces partitioning of a system state 
into small, self-contained objects. 


e Objects are reactive, by which we mean that an object will do nothing but maintaining its 
state until it receives an external request to execute some action. Actions may involve an 
arbitrary amount of computation and communication, but, in the absence of non-termination 
and deadlock, every object will eventually enter a resting state again. There are no iterative 
loops in this model. 


e Objects are independent and may evolve in parallel. Both synchronous and asynchronous 
communication between objects is supported, and mutual exclusion between different actions 
of an object is guaranteed. Thus, we identify the notions of objects and processes. 


e It uses a functional sublanguage with non-strict semantics to express computations. This sub- 
language retains all the semantic properties of pure functional languages like Haskell [HJW+91]. 
In particular, any Haskell program not depending on a particular I/O model can easily be ex- 
pressed. 


e Expressions are only evaluated on demand by objects during action execution. There is no 
print-loop involved, and no particular main expression. A crucial property is that expression 
evaluation can neither cause nor detect any state change in the object world. 
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e Objects may be created dynamically at run-time by instantiating object templates, and the 
configuration of objects may be dynamically changed, by sending messages containing object 
references. 


e Input is modelled as a request to execute some action of a certain object, while output is a 
state-change of some object belonging to the environment. This model extends naturally to 
include the treatment of input as interrupts and output as the state-change of hardware objects 


like the display memory. 


e Actions, references and templates are first-class values, which means that they may be used 
as parameters, function results, data structure members, and state contents. This allows large 
systems of objects to be decomposed into smaller ones in a way very similar to hardware design. 


It is important to note that this asymmetric two-level design does not permit the use of action 
execution in the encoding of functions. This means that we support imperative algorithmic pro- 
gramming no better than, say, Haskell. As we have mentioned, the purpose of our work is to make 
object-oriented, reactive I/O available to the functional programmer. However, the undistorted se- 
mantics of our functional sublanguage should enable any functionally consistent imperative extension 
to be directly applied, if desired. How this can be achieved without introducing different notations 
for similar concepts is an area of future work, though. 

We will continue this paper by giving a brief overview of Omelett', a language designed to illustrate 
our notion of reactive programming. Then, in section 3, we will present some non-trivial program- 
ming examples using this language. In section 4 we will give the formal definition of the dynamic 
semantics of Omelett. The paper concludes in section 5 with a comparison to related work. The 
most obvious omissions from this presentation are the issues of static semantics and implementation 
techniques, matters which are fully covered in our licentiate thesis [Nor94]. 


2 Overview of Omelett 


A central idea behind our approach is the distinction between a computation, which serves to deliver 
a result as fast as possible, and a simulation, which maintains a possibly infinite interaction with 
its environment. In this setting, a compiler performs a typical computation, while a text-editor is 
engaged in a simulation (of a type-writer in this case). A similar distinction can be made between 
the use of values and objects in programming languages. In our terminology, values stand for the 
constant, timeless abstractions we know from mathematics. This contrasts to objects, which are 
concrete models of the real world where terms like state and change are valid. Arguably, the value- 
oriented and object-oriented programming styles are ideally suited to the tasks of computation and 
simulation, respectively. 

Omelett supports user-defined values as well as user-defined objects, by means of two distinct kinds 
of type-declarations. Having both notions at hand within the same language gives the programmer 
freedom in choosing the best representation at every stage: if something can be thought of as having 
a unique identity throughout potential state changes, it should be coded as an object; otherwise it 
should be coded as a data value. 

We may illustrate this philosophy by a small example. Take the concrete activity of repainting a 
red car with blue color. In a functional style, this has to be interpreted as the definition of a new car 
value, distinct from the red one. Under the object-oriented paradigm we may retain the identity of 


' Object-oriented MEta Language ETT (1). 
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the car object, but we run the risk of accidentally changing the meaning of object “red” instead. In 
the combined, reactive style of Omelett, we are able to code the example according to our intuition. 
By treating the car as an object and the colors as values, repainting is formulated as the action 
that changes the color-state of the car from the value of red to the value of blue. We run no risk of 
disrupting the meaning of any expression because of the state change, still we automatically capture 
the idea that the repainted car is the same as the old one. 

The example looks as follows when coded in Omelett: 


data Color is 
Red 
Green 
Blue 


object Car is 
orig_color :: Color 
currcolor.:;.. LsColor 
repaint s2uCOLOT ma oat! 


template car init_color is 
orig_color = init_color 
action curr_color does 
reply color 
action repaint new _color does 
set color = new_color 
state color = init_color 


new my_car <- car Red 


Here Car is the name of a new type whose values are references to objects having the visible attributes 
orig_color, curr_color, and repaint. A template for such objects is obtained by applying car 
to a value of type Color. This is done in the new construct on the last line, which binds my_car 
to a fresh object reference of type Car. It should be emphasized that all three attributes are really 
constant values; for example, curr_color is not a value of type Color, but a synchronous action 
whose replies are of type Color. Such a reply may only be collected by some other action under 
execution, by writing 


req c <- my_car.curr_color 


Likewise, the color of my_car may only be changed by means of the asynchronous form of the same 
command: 


req my_car.repaint Blue 


These actions may be requested in parallel by multiple objects — the semantics of objects still 
guarantees that my_car will execute at most one of its actions at a time. On the functional level, 
though, it is only possible to select action values, not to request their execution. We may say that 
an action value is a reaction capability, that can only be utilized outside the language of expressions. 
This is the feature which makes expression evaluation free from side-effects. 

The full syntax of Omelett is given in figure 17. A few further remarks may help clarifying its 
intended semantics: 


?In this grammar we take the liberty to let a postfix s denote a sequence of the non-terminal to which it is attached. 
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prog 


tdecl 


constr 
select 


type 


tdecls decls 


data tcon tvars is consirs 
object tcon tvars is selects 
con types 

sel:: type 


tvar 

tcon types 
type -> type 
* type 

type 


bind 

new gens 

template var vars is atirs state binds 
bind 

new gens 

action var vars does cmds 

var = expr 

var <- expr 


var 
con 

\var -> expr 

expr expr 

ezpr. sel 

let binds in expr 
case ezpr of ealts 
con vars -> expr 


set binds 

new gens 

req ezprs 

req gens 

reply ezpr 

let binds 

case ezpr of calts 
con vars -> cmds 


Figure 1: Omelett syntax 
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Top-level declarations 


Inductive datatype 

Object reference type 

Data constructor declaration 
Attribute selector declaration 


Type variable 

Saturated type constructor 
Function type 

Template type 
Synchronous action type 
Asynchronous action type 


Standard global declaration 
Global object declarations 
Template declaration 
Standard attribute 
Sub-object attributes 
Action attribute 


Value binding 


Generator 


Variable 

Data constructor 
Abstraction 
Application 

Attribute selection 
Local bindings 

Case analysis 
Expression alternative 


Assignment 

Object creation 
Asynchronous action request 
Synchronous rendezvous 
Rendezvous reply 

Local bindings 

Case analysis 

Command alternative 


e Only action commands may refer to the state variables of a template. This restriction partic- 
ularly precludes state dependent attributes. 


All template declarations are automatically in the scope of the pre-declared variable self. 
This variable becomes bound to the actual object reference created during instantiation. 


The new construct appears as a global declaration, as an attribute, and as an action command, 
but not as an expression alternative. If the latter form were allowed, objects could be created 
as a side-effect of evaluation, and referential transparency would be lost. 


e Assignments and object instantiations are performed lazily, just like local bindings. This makes 
the case and the req commands the only real forces behind expression evaluation. 


3 Some example programs 


In this section we will examine two simple, but nevertheless typical programming problems. The 
examples are of necessity incomplete, but we think that they still serve the purpose of illustrating 
some of the main features of reactive programming. In order to make the examples look less esoteric, 
we will use conventional syntax for numbers, strings, and lists, and we will also make some limited 
use of established functional language features like pattern bindings and list comprehensions. 


3.1 Controller for an autonomously guided vehicle 


Our first program illustrates the separation between the computations performed by a program, 
and the simulation in which it is involved. Since it is an example of an interrupt-driven system with 
parallel processes, which also performs heavy calculations, it captures many of the characteristics of 
a typical stand-alone, industrial system. 

The concrete task is to control an autonomously guided vehicle (AGV). Such a vehicle is capable 
of navigating (within a limited area) without the guidance of a human driver. The crucial point for 
an AGV is to know its position at all times. There are different methods developed for this purpose, 
the one we will consider in our example relies on the existence of a set of reflectors placed out at 
known positions within the room in question [Hyp87]. To determine its position, the AGV measures 
angles to the visible reflectors by means of a rotating laser beam. The angles are then compared 
with the positions of the reflectors, to yield a position within the room from which the angles must 
have been measured. If this position does not coincide with the desired position at that time, a 
regulating algorithm generates appropriate adjustments to the driving and steering servos. 

Our first step in programming a controller for such an AGV is to separate the two major algorithms 
— positioning and regulation — from the questions of hardware interaction. The algorithms, called 
calcpos and regulate, are of course coded as functions, but since their implementation mainly 
concerns matters that belong to the field of control theory, we only give their type signatures (using 
a syntax similar to the selector declarations). Figure 2 shows the resulting code. 

Viewing the system from the outside we identify three main objects (or processes): the angle- 
meter, the simulated driver, and the servo. These objects are defined by giving their interfaces (the 
object types) as well as their implementation templates. 

The AGV controller must obviously be a sampling system, and the clock driving this implemen- 
tation is actually the rotating beam, which issues a zero-crossing interrupt (tick) at the completion 
of each turn. The interrupt is reacted to by the angle-meter action zerocross. Furthermore, during 
the scan of the beam, the meter hardware generates another interrupt at each detection of a reflector, 
which is handled by the action detect within the same process. 
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calcpos :: [Angle] -> [Pos] -> Pos 
regulate :: Pos -> Pos -> Speed -> Speed — 
room a2 Cros) 


object Driver is 
newscan :: [Angle] -> !! 
newpath :: [Pos] -> !! 
object Meter is 
detect su 
zerocross :: !! 
object Servo is 
setspeed :: Speed -> !! 


template driver s is 
action newscan angles does 


let current = calcpos angles room 
desired:path’ = path 
speed’ = regulate current desired speed 


req s.setspeed speed’ 
set speed = speed’ 
path = path’ 
action newpath p does 
set path = p 
state speed = zero 
path = cycle origo 


template meter d is 
new angle_reg <- in_port angle_reg_addr 
action detect does 
req a <- angle_reg.read 
set angles = a:angles 
action zerocross does 
req d.newscan angles 
set angles = [] 
state angles = [] 


new d <- driver s 
m <- meter d 
s <- servo .. 


Figure 2: A controller program for an autonomously guided vehicle 
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In the body of detect we touch the issue of how concrete hardware interaction can be performed. 
The angle-meter process has created a subobject angle_reg at startup, by instantiating a template 
in_port which we assume is primitive. Because of the address given to in_port at instantiation, 
angle_reg maps to the actual hardware register that contains the current angle of the beam, and 
this angle is read by detect and inserted in the list of angles collected during the present scan. 
When a zerocross interrupt is issued, the angle-meter process sends the accumulated list to the 
driver process, and clears its local state. 

The state of the driver process consists of the current speed vector, and a list of positions that 
constitute the path that the AGV has to follow. The path list is consumed one element per system 
tick, and in order to make our example simple, we have assumed that the list is infinite. Thus, to 
make the AGV stop, the path must contain the same position repeatedly. The driver action newpath 
can be requested at any time to give the AGV a new path to follow. We are not concerned here 
with the possible origins of such requests, however. 

At each tick, the angle-meter process sends the detections of the completed scan to the driver by 
requesting the action newscan. The body of this action has in fact only two concrete activities to 
perform: to update the servo with a new speed vector, and to advance the path state by one step. 
The remaining issues of newscan are preferably expressed in the functional domain, using the let 
construct at the beginning. 

The servo process is only given as an interface. It may be implemented in hardware directly, or it 
may be a software object of any complexity. All that we need to know is that it accepts new speed 
vectors by means of an action named setspeed. 

Finally, the global new declaration ties it all together, by instantiating processes (objects) from 
the templates. What we have not shown is how the interrupts of the system are directed to the two 
actions of the angle-meter process. Since this coupling actually forms the “top” of a stand-alone, 
reactive system, we could imagine a convention that requires the interrupt vector table to be declared 
in the program text under the name main. 


3.2 Desktop calculator 


The next example of a reactive program is a “desktop” calculator, a common application under 
modern operating systems that utilize the desktop metaphor as its user interface. Apart from 
illustrating how a typical interactive program can be coded in Omelett, it also shows an application 
of both higher-order functions and higher-order actions. 

In this example we will rely on the existence of a graphical user-interface library, based on the 
notion of graphical objects of type View. A view is an object capable of drawing a representation of 
itself on the screen, and the library is assumed to contain templates for many different view objects 
like buttons, text displays, windows, menus, etc. Furthermore, the run-time interaction with the user 
is supposed to be administered by a view manager process, which takes care of tasks like reacting to 
mouse movements, redrawing the screen, and directing input events to the view pointed to by the 
mouse. Our job is to supply a template that defines the unique characteristics of a calculator view. 

Figure 3 shows our implementation of the calculator template. The looks of the calculator are 
defined by instantiating a view structure starting at attribute body, utilizing primitive view templates 
(button and display) as well as designated layout templates (matrix and vbox) fetched from the 
library. In the declaration of the digits attribute, we see an example of how list comprehensions 
can be used to generate lists, in this case a list of button templates. Omelett lets the new construct 
(as well as the req commands) distribute over lists, so the result of the instantiation will be a list of 
button objects, bound to the name digits. 

The button template is parameterized with respect to a button label and an asynchronous action 
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display :: String -> *View 


button :: String -> !! -> *View 
matrix :: Int -> Int -> [View] -> *View 
vbox :: [View] -> *View 


template calculator is 


new displ <- display "0" 
digits <- [button (show n) (do_digit n) | n <- [0..9]] 
ops <- [button (show f) (do_op f) | f <- [(+),(-),(*),(/)]] 
pad <- matrix 4 4 (button "ENT" do_enter : 
button "CLR" do_clear : 
digits ++ ops) 
body <- vbox [displ,pad] 


action do_digit n does 
set fst = 10 * fst +n 
req displ.draw (show fst) 


action do_enter does 
set fst:rest = O:fst:rest 


action do_op f does 
case rest of 
snd:rest’ -> 
let result = f snd fst 
set fst:rest = result:rest’ 
req displ.draw (show result) 
[] -> 
req env.beep 
action do_clear does 
req displ.draw "0" 
set fst:rest = [0] 


state fst:rest = [0] 


Figure 3: A desktop calculator 
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that the button objects should request when hit by the mouse. The action argument is formed by 
applying the local action do_digit to the number of the button. It is important to observe that 
this application does not imply any ezecution of do_digit at this point. As we have stressed before, 
action values only denote the capability to react, not the reaction itself. The situation is more or 
less the same in the instantiation of the ops attribute; here the arguments to the local action do_op 
are functions. In order to avoid clutter, we have assumed that there exists a function show that 
returns a suitable string representation of functions (!) as well as numbers. 

There are two more actions in the calculator template, do_enter and do_clear, which correspond 
to the “ENT” and “CLR” buttons of our calculator, respectively. Furthermore, the internal state 
of the calculator is a stack of numbers, defined using pattern matching to get separate names for 
the first element and the rest of the stack. When requested, that is when a graphical button is hit, 
do_digit will update the head of the stack and redraw the display. If the “ENT” button is pressed, 
a 0 is pushed on top of the stack, but the display is not redrawn in order not to confuse the user. 

do_op requires at least two numbers on the stack, or else it will issue a “beep” request to some 
global object env. If there are enough numbers, the function parameter (which will be (+), (-), 
(*), or (/), depending on the button pressed) is applied to the two topmost elements, which are 
replaced with the result. Finally, the result is drawn on the display. The behaviour of the last action, 
do_clear, is obvious. 


4 Operational semantics 


In order to formally define the semantics of Omelett, we need a way of representing objects and 
references which is consistent with the representation of lazy evaluation, where sharing and updating 
must also be easy to express. Our approach is to build on work by Launchbury [Lau93], who defines 
an operational semantics for lazy evaluation by modelling the run-time heap as a set of recursive 
bindings, where the variables take the role of pointers. This of course requires all bound variables 
to be distinct, and we will simply assume that the Omelett source is accordingly renamed to begin 
with. 

Before that, however, we need to perform some slight source transformations, so that we can 
express all global declarations and attribute bindings on the var = ezpr form. This requires the 
following addition to the syntax for expressions: 


expr — > action varcmds | {cmds | vars | ao} 


Here the first expression form represents an action value (tied to a specific object via the var compo- 
nent), while the second form will constitute object nodes in the heap. Object nodes are introduced 
in the transformation of templates, which are turned into functions abstracting out the variable 
self from an object node. This scheme also makes object instantiation easy — it just becomes the 
binding of an object name (reference) v to the template expression applied to the same v. Figure 4 
gives the complete transformation scheme. 

An object node has three components: a current command sequence representing its “program 
counter”, the roots of its attribute expressions, and its local state. The state is modelled as a 
substitution, which binds the state variables (free in the action bodies) to variables denoting the 
current state contents. We use o to range over substitutions, and a standard postfix [co] notation 
for the renaming of a construct according to a. Unique variable names are generated within the 
meta-function NEW(), defined by: 


/ 


’ are fresh variables 


NEW(%...Un) = VU =U, -++ Un =v where v,...v 


action v vsdoescs ~ v2\vs > action self cs 


template v vsis bs state bs ~ v=\vs > \self > let bs + bs'[o] 
in {_ | pv(bs) | a} 


where ¢ = NEW(DV(bs’)) 


new; <€; ++: Un en ~~ let v, =(€; M1) *** Un = (En Mn) (commands) 


new 0, <6) +++ Sen SV, = (€, M1) *°* Un = (En Un) (declarations/attributes) 


Figure 4: Initial transformation of Omelett source 


Our meta-notation furthermore lets _, :, and++ stand for the empty sequence, sequence construction, 
and sequence concatenation, respectively. We will also use © as an alternative to +, for both 
forming and matching against sequences where the actual order is irrelevant. Dv(6s) finally denotes 
the variables defined in bs. 

The operational semantics is defined as a transition system between abstract machine configura- 
tions. We actually make use of two transition relations, => and |} , where => defines command 
execution, and |} defines expression evaluation. A configuration is just a heap (I) in the former 
case, and a pair of a heap and an expression (T > e) in the latter. The asymmetry in our combina- 
tion of object- and value-oriented programming is evident in the semantics in the sense that => is 
defined in terms of J} , but not vice versa. The initial configuration of the system is the heap formed 
by the transformed and renamed source code, and the meaning we assign to our programs is the set 
of possible configuration sequences defined by =>. Figure 5 shows the full set of transition rules. 

The semantics of expression evaluation (rules a to 7) is straightforward, we particularly note that 
the two additions to the expression syntax form canonical values (rules h and 7). The hat notation 
é in rule a is Launchbury’s syntax for dynamic renaming of bound variables in e. This renaming is 
necessary in order to keep the program distinctly named, since expressions referenced by name may 
be shared. Renaming is trivial and need not be defined here, we only have to note that the variables 
introduced in the two extra expression forms are not binding occurrences. Apart from the addition 
of objects and action values, the remaining difference between our formulation and Launchbury’s 
semantics is that we put function arguments in the heap, as if they were local bindings. Launchbury 
instead does meta substitution of the argument in the function body, but this requires explicit 
naming of every argument in order to preserve laziness. Our approach is more straightforward, 
but it also means that we introduce an extra level of indirection for arguments which already are 
variables. However, since we are not primarily interested in the space behaviour of programs, this 
has no significance. 

The rules defining command execution (j to p) focus on a specific object node, which must 
generally be chosen non-deterministically. Since the expressions embedded in a command sequence 
may contain free state variables, these must be replaced by the actual state at the point of each 
command, hence the application of [a] at various occurrences in rules 7 to p. Unfortunately, the 
assignment rule 7 looks more complicated than it is, due to the fact that our heap notation is 
inherently recursive, something which the assignment command is not. 

The three rules which refer to the |} relation (rules / to n) use (---) as an abbreviation for the 
object(s) in focus, to express that evaluation will take place in the context of the complete current 
heap. Rules m and n show the difference between asynchronous and synchronous requests, in that 
the latter rule is only applicable when the recipient is inactive. Furthermore, the coupling between a 
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Figure 5: Operational semantics of Omelett 
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synchronous sender and the receiver must be maintained until the receiver issues a reply; to achieve 
this we apply a small trick which replaces the sender’s generating action expression with a reference 
to the receiver (v’). This reference (which can never evaluate to an action expression) uniquely 
determines the objects which may participate in a reply data transfer (rule o). 

The non-deterministic choice which must generally be made in the => rules is our current 
definition of the intuitive parallelism between objects. This definition is admittedly of a rather 
coarse grain, since it does not allow any change of focus during expression evaluation. A definition 
based on a small-step evaluation semantics would of course be more coherent with a real parallel 
implementation (albeit at the price of increased complexity), and such a reformulation is a natural 
target of future work. 

We have not yet undertaken a formal proof that the semantics of lazy expression evaluation is left 
unaffected by its inclusion in an object-oriented context. Still, we think that our claim is informally 
justified by the following observations: 


e Rules a to f are essentially a copy of those defined by Launchbury [Lau93], who proves that 
his semantics is computationally adequate with respect to a denotational semantics for lazy 
functional languages. 


e The action and object expressions are canonical (rules A and 7), which means that they could 
have been modelled by the constructors of an ordinary datatype. The action expression is even 
degenerate, since action values cannot be scrutinized within the expression sublanguage. 


e The selection expression discards the state-dependent components of object nodes completely 
(rule g), thus the dot-operator can be considered identical to purely functional record selection. 


All the object manipulating rules (7 to p) preserve the attributes component of object nodes, 
as well as the contents of any node which is not an object. . 


Updates due to rule a cannot affect the consistency of rules 7 to p, since the object nodes in 
focus are already on canonical form. 


5 Related work 


Our work is to a large extent inspired by a paper by MacLennan, who investigates different applica- 
tions of objects and values in programming laguages [Mac82]. His discussion is very general, so the 
question of what a concrete, combined language should look like is left open. Unfortunately, we are 
not aware of any further work by MacLennan in this direction. Reactive is a term coined by Pnueli 
to classify programs which are not purely transformational [Pnu86], and we believe our use of the 
word is a rather faithful extension of his view. Likewise, we borrow the idea that program execution 
can be seen as a simulation from the tradition of object-oriented languages, starting with Simula 
[DMN70]. 

Hudak and Sundaresh [HS88], Carlsson and Hallgren [CH93], and Gordon [Gor93], address basi- 
cally the same problems as we do in their work on functional I/O systems. The solutions they present 
can all be characterized as (collections of) purely functional programs, managed by an anonymous, 
unpure operating system which handles updates to the system state and supports non-deterministic 
merging of events. Our approch can be said to move this “unpure” part inside the programs, but in 
such a way that the purity of expression evaluation is maintained. We see several advantages by this 
move: state-manipulation is more direct and intuitive than in a continuation- or stream-based style, 
there is no need for an additional operational interpretation of the values computed by a program, 
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and we expect programs to be easier to compose and extend when even the “operating system” is 
in the hands of the programmer. Of course this comes at the price of introducing new primitive 
ideas such as objects, actions, and commands, but we believe that an adaption of these concepts 
will actually prove beneficial in the construction of large, reactive programs. 

Current research in extending functional languages with state is mostly motivated by the need for 
efficient encodings of inherently imperative algorithms. In the context of lazy evaluation, this field is 
represented by a succession of achievements, headed by the work of Launchbury and Peyton Jones 
[LPJ94, ORH93, Hud92, SRI91]. These solutions focus on how to encapsulate state-manipulating 
threads inside apparently pure functions; to the extent that I/O is considered, it is viewed as a special 
case of an imperative calculation, analogous to the treatment of I/O in traditional languages. Since 
our goal is of a very different nature, our approach notably lacks the ability to treat state-threads 
as functions. Still, we may identify several similarities between our reactive model and the work of 
[LPJ94]: laziness and referential transparency is preserved for all expressions, state references can 
be part of data-structures manipulated by ordinary functions, and there are no restrictions imposed 
on the polymorphic type-system. The most obvious advantage of the reactive model is its ability to 
partition the global system state into self-contained, parallel objects. 

There are several languages that provide mixtures of functional, object-oriented, and parallel pro- 
gramming. Holmstrom presents a language for parallel functional programming with an asymmetric 
structure similar to ours [Hol83]. Although based on the almost-functional language ML, it has 
the important property that the meaning of expressions is preserved through state changes on the 
outer, parallel level. Holmstrom’s language is different from ours, though, in that it models state im- 
plicitely via parameterized behaviour expressions, and the object-oriented notion of unique objects is 
replaced by anonymous behaviours communicating over unique channels. CML and Erlang are two 
examples of parallel-functional-hybrids which have been successfully used in real-life applications 
[Rep92, AVW93]. However, both these languages mix expression evaluation with communication 
primitives, so they must resort to strict evaluation semantics. Still, the notion of higher-order con- 
currency in CML has some interesting similarities to our treatment of actions as values. 

From the object-oriented tradition stems POOL, with its notion of parallel objects [Ame85]. 
Functions are not primitive in POOL, however, instead these are defineable as actions without side- 
effects, at the responsibility of the programmer. This route is also taken in two languages that mix 
object-orientation with concepts from functional programming: LOOP, and UFO [ESTZ94, Sar93]. 
The advantage of these approaches is of course smaller language definitions, but as a consequence, 
many benefits of functional languages are lost. Whether our approach represents an acceptable 
compromise between language complexity and desirable program properties remains to be seen. 
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1 Introduction 


In recent years, a number of concurrent programming languages have been based around applicative 
languages. Best known are CML [Rep92], Facile [GMP89] and LCS [Ber93], all extensions of 
Standard ML [MTH90]. One would of course want to extend the type inference paradigm of 
Standard ML [Mil78] to cope with the new concurrency constructs. 

Recently, the effect type discipline proposed by Lucassen [Luc87] and Talpin and Jouvelot [TJ92] 
has attracted a lot of interest as a possible means of capturing these non-applicative aspects, the 
idea being to associate with an expression not only its type but also the side effects of its evaluation. 

Nielson and Nielson have proposed a monomorphic effect type discipline for CML [NN93]. Here 
the effect of executing a CML expression was a process calculus term. In [Tho93] Thomsen proposed 
a very different effect polymorphic effect type discipline for the Facile language, and independently, 
in [BD94] Bolignano and Debabi gave a very similar type discipline for a subset of Concurrent ML 
— here, the effect of a program is the sort of the program, i.e. the set of communication channels 
used and all causality is absent. 

In this paper we consider Ainda, a concurrent applicative language based on a rather different 
concurrency paradigm, namely the Linda concept of Gelernter and Bernstein [GB82], and give a 
type system where effects are described by expressions in a process calculus. 

The type inference system proposed in this paper introduces a novel combination of two previous 
solutions that have been used to deal with a problem peculiar to applicative programming languages, 
that of determining the polymorphic effect type of functions. Should one use subtyping or effect 
polymorphism? We argue that a combination is needed. We give a sound type reconstruction 
algorithm based around our idea. 

Proofs of all results stated in the paper are found in [KJH94]. 
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2 Ainda 


Ainda adds the Linda concept of [GB82] to an applied call-by-value A-calculus. Linda is based on 
the notion of a tuple space, a shared memory visible to all processes. A tuple space is a multiset 
of tuples — a tuple consists either of data or evaluating subprocesses. Each process in the program 
can modify the tuple space by depositing or removing tuples. 

As tuples were simply a particular data structure introduced in the original implementation 
of Linda, we generalize the notion to that of processes. In Ainda any meaningful expression can 
be deposited in a process space which is a multiset of expressions. Four primitives are used to 
manipulate the process space: in removes expressions, rd copies expressions from the process space. 
out deposits values and eval deposits expressions to be evaluated. Communication through a process 
space is asynchronous — processes only block if the expression they want to input does not exist in 
the process space. The choice of which expression to retrieve is made by pattern matching; Ainda 
extends Linda in that patterns are first-class objects. Further, we extend Ainda with multiple 
process spaces to gain the possibility of encapsulation. 


2.1 Syntax 
The syntax of Ainda expressions is 


v|z|e,e2| if e then e; else e. | let r =e, in eg | recr(y)-e 
ssuedtAr-e Sev] 25204 > 


e 


Values are thus either constants, \-abstractions or closures. The latter handle function constants — 
see below. Variables x range over the set Var. rec r(y)-e defines a recursive function with parameter 
y and body e possibly containing recursive calls (occurrences of 2). 

The. constants of Ainda have the abstract syntax 


c ::= () | true | false | n |p| pair | fst | snd 
| nil | cons | head | tail | isnil |? | in | rd | out | eval | makeps 


The set of constants includes the basic values: () of unit type, the booleans, integers n € Z, and 
process space identifiers p € PS-id. The latter cannot be written as literals but only appear as the 
result of creating a process space by makeps. The set of constants includes operators for making 
pairs and lists and the operators for communication: ’?’ is a pattern matching any value, in, rd, 
out and eval are the Linda primitives, and makeps is used to create new process spaces. 

2.2 The Operational Semantics of Ainda 

The operational semantics of Ainda has a sequential level dealing with the evaluation of a single 
expression and a concurrent level dealing with the evolution of the process spaces. 


Sequential Evaluation 


The semantics of the sequential evaluation is based on the notion of evaluation contexts of [Rep92]: 
Eo := []|He|v£|letz = E ine| if E then e, else eo 


Any Ainda expression is a completed evaluation context E[e] containing the subexpression e to be 
evaluated; the definition of & ensures call-by-value semantics, c.f. the operational rules in Table 1. 
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[app1] E{(Az-e) v] —+ Ele{u/z}] 
[app2| Elvy v2 72] —> Elvs] lif |(vi, v2, 03) € A 


(if1] E[if true then e; else e2] —~> E[e1] 

(if2] E[ if false then e; else en] —+ Efeg] 
[let] E{let 2 =v ine] —+ Ele{v/z}] 

free] —Elreca(y)-e] + Bl(Ay-e){ (rec 2(y)-e)/2}] 
fin] Bene Sig) ee) B05) 

ird] joicenes iM MRL at 
[out] E{< out v1> v9] cee E{()] 
[eval] Ef< eval v1> va] pees eens E(()] 
jaa Fifertakens-() seen aera 


Table 1: The semantics at the sequential level 


These define a labelled transition system with labels / denoting the communication occurring (if 
any): 


1 ::= in(v1, v2, v3) | rd(v1, v2, v3) | out(v1, v2) | eval(vi, v2 ()) | makeps(v) | € 


with e denoting internal computation. 

The rule [app2] states that the application of two values (v;, v2) can evaluate to a third value v3 
if (v1, v2, v3) € A. A, defined in Table 2, only deals with the first argument of the Linda primitives 
as application of the second argument has a side effect on the whole system and is handled by the 
rules for Linda primitives. 


v, <pairu>), 
eran a1 v2, <pairv, v2>), 
fst, <pairv,; ve>, v2), 

<pairv, v2>, v2), 

v, <in v>), 

v, <evalu>) 


( 
( 
( 
(snd 
(i 
( 


Table 2: Clauses from the relation A dealing with evaluation of function constants 


Concurrent Evaluation 


A Ainda program is a pool of process spaces. A process space S € ProcSpace is a multiset of 
expressions tagged with their type. S{e:t] here denotes that e:7 is an element of S. The pool of 
process spaces W maps process space identifiers to process spaces, i.e. W € PS-id~ProcSpace. 

The semantics of the concurrent evaluation is shown in Table 3. The evaluation of the Linda 
primitives within an expression results in a change to a process space. out and eval both result in 
the addition of an expression to a process space ({PSP-out] and [PSP-eval]). in removes a value 


at 


E ! 
Ca ee 


(PSP-elem| Wp Sle:7])] > Wp Sle: 7] 
[PSP-make] ¢ TAKPSP) e! p! ¢ |dom|(W) 


W [p> Sle: 7]] —~ W [pr S[e’: T],p’ > 0 


out(p2,v 
e (p2,v) el 


sears a a RREKT iF" Set PTS Sel ee a ae ie gue 
| sey ust Sles tose es nies el eri, oe aoa 


eval(p2,e”) l 
Che oe i € 


PSPzevalacn to «elo Sopoelase amen oleeing,. _ an 
W [pr ret ¢ Sle : T]| — W [pe — W'(po) lw {le . rh where W W[p1 Sle l| 


iN(p2,v1,03) 
———— 


fas) 


e! Vg:TZE W (po) v3 = match(v; ym Ee T2) 


[PSP-in] Se 
W [pi + Sle: 7]] —> W [po 4 W'(p2) — {v2 : T2}] 


where W'=W([p1 ++S{e':7]| . 


[PSP-rd] e rd(p2,1,03) e! v2:T2€ W (p2) v3= match(v; 2 ili Us T2) 


W [p, > Sle: 7]]| —>- W [pi 4 Se’ : 7] 
Table 3: The semantics at the concurrent level 


if it matches the pattern ({[PSP-in]), and the rd primitive acts as the in primitive except that the 
value is not removed ([PSP-rd]). 

Observe that the rules [PSP-out] and [PSP-in] introduce an ordering of the changes: the pro- 
cess space containing the active expression is changed and only then is the process space being 
manipulated changed, as the two references may refer to the same process space. 


Matching 


Values are input or read from the process space using pattern matching; in Ainda patterns are 
first-class objects and have the type r pat. A pattern can be either a ’?’ or a concrete value. 

The types of patterns are all-important; here we shall assume the presence of the needed types 
(as provided by the type reconstruction algorithm of Section 4.4). The predicate match first matches 
the types of the values and then the values themselves using the auxiliary function vmatch. If 
successful the result of match is the value to be the result of the in or the rd. 


match(v; : T”’pat”,vg:T) = vmatch(v1, v2) 
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where vmatch is defined as 


vmatch(v, v) = v if v is not a A-abstraction 
vmatch(?, v) = vu 

vmatch(v, ?) = vu 

vmatch(<pair v, ve>, <pairv3 v44>) = <pair vmatch(v;, v3) vmatch(v2, v4)> 
vmatch(<cons v1 v2>,<cons v3 v4>) = <cons vmatch(v1, v3) vmatch(v2, v4) > 


Note that A-abstractions can only be matched by ’?’. 
It is possible to output values containing ’?’ into the process space. To input a’?’ the pattern 
used must be a pattern for a pattern, i.e. have the type (7 pat) pat. 


3 A small example 


In this section we will demonstrate how to create parallel programs in Ainda by creating a parallel 
quicksort algorithm. The main function in the quicksort algorithm is the function split which splits 
a list into two parts: one where the elements are smaller than or equal to the pivot element and 
one where the elements are larger. The function split looks like this: 


split=Apivot-Alist- 
if isnil list then 
(0.0) 
else 
let 
element=head list 
result=split pivot (tail list) 
in 
if elementj=pivot then 
(element::(fst result),snd result) 
else 
(fst result,element::(snd result)) 


In a sequential quicksort the sort function is called recursively on the splitted parts of the list, 
after which the parts are concatenated into a single sorted list. A sequential version of quicksort 
could look like: 


quicksort=Alist- 
let 
result=split (head list) list 
smaller=quicksort (fst result) 
larger=quicksort (snd result) 
in 
smaller++larger 


Note that we use ’++’ as concatenation of lists and for convenience the pivot element is chosen as 
the first in the list. 

The idea in the parallel version is to spawn a new process for each recursive function call. So 
each time a list is divided into two parts by split two new processes are started to sort the parts. 
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When the new processes terminate they become passive elements in the process space containing 
the sorted sublists. Now the original process needs to collect the results in the right order. So we 
need to know how to find the right parts of the list which we want to combine into the resulting 
list. To this end each result of the partial result is tagged by a number indicating which part of the 
list it is, such that each time a split occurs the two new processes are numbered 2n and 2n + 1. 


sorter=Aps- Apart: Alist: 
if isnil list then 
(part, list) 
else 
let 
(smaller,larger)=split (head list) list 
in 
eval ps (Au-sorter ps (2*part) smaller); 
eval ps (Au-sorter ps (2*part+1) larger); 
let 
smaller=snd (in ps (2*part,?)) 
larger=snd (in ps (2*part+1,?)) 
in 
(part,smaller++larger) 


Finally, we need the main function starting the quicksort: 


quicksortpar=Alist-snd (sorter (makeps ()) 1 list) 


This example shows a commonly used principle in Ainda programs, which is to tag the values 
in the processes space such that it is possible to decide which value is the result of which process. 
In this example the tag is a unique number but often the tag is a string indicating what the value 
is. This also provides the ability to distinguish between results from different programs/algorithms 
evaluating in parallel. 


4 An effect type system for \inda 


In the rest of our paper we shall consider an effect type system for Ainda. The ype of an expression 
is T&x, T being the ordinary type and « the effect of the expression, denoting the communication 
capabilities of the expression; inspired by work of Nielson and Nielson [NN93, NN94], effects are 
terms from a process calculus and can be given an operational semantics, giving us a tool to show 
that the behavioural effect of an expression is indeed sensible. 

The types 7 have the following syntax: 


7 a= Bia Toss) THist! Ty | 7 pat | ps p 


where a € TypVar denotes type variables. 
The syntax of process behaviour types Bexp is: 


B B+B|B;8|ybB|blale 
a out(p, 7) | eval(p, T&) | rd(p, 7) | in(p, 7) | makeps(p) 
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Here +’ denotes nondeterministic choice, ’;’ is sequencing, yb-G describes recursive behaviour, where 
b ranges over behaviour variables BehVar, a € Act is the possible actions, and ¢ denotes the empty 
behaviour. p € Reg denotes regions. 

Regions, though not essential to our approach, facilitate the semantics of behaviour types 
presented in Section 4.5. A region intuitively corresponds to the notion of process space — a region 
is a set of “program points” stating which process spaces a Linda primitive have access to. A region 
identifier should be thought of as being associated with occurrences of makeps. Regions p are given 
by: 


p s= t|r|piUpe 


where i € RegId denotes the region identifiers, r € RegVar denotes region variables and ’U’ 
denotes the union of regions. 


4.1 Determining the behaviour of a function 


In [NN93] subtyping was used to give behaviour types to CML in a monomorphic setting where 
the programmer has to state the type of the arguments to functions; whereas polymorphism was 
employed in [NN94]. To see which solution is the most appropriate consider the following two 
problems. 


The Argument Problem 


The argument problem arises from the fact that functions bind behaviour. If the argument of a 
function is itself a function, the behaviour of the function may depend on the behaviour of the 
argument. A related problem is that of the latent behaviour of a function input from a process 
space. At compile time we have no simple way of determining this behaviour. 

To see how the argument problem is handled using subtyping consider this expression 


M-(f (in ps(? : int))+7 


The type of this expression should be (int ear int) —*.. int where the behaviour G of the function 
should contain the behaviour £7’ of f. Since we want an upper bound for the possible communication 
we have to assume that the argument has every possible behaviour. If we let co denote every possible 
behaviour the functions get the type 
(int — int) oS int 

In the case of higher-order functions, the application of an argument yields another function. This 
function also has a bound behaviour but now we can be more specific about it as we know the 
behaviour of the argument given. Therefore we have to keep track of the origins of the oo’s in 
the effect when dealing with successive applications and instantiate them correspondingly. This 
amounts to using the oo’s as polymorphic effect variables. By using polymorphism at the level of 
effects, we can easily solve the argument problem- — we use a generic behaviour variable representing 
the unknown behaviour contained in f. The type of our expression becomes 


Yb-(int —- int) cidlesdlt hak. int 


Sy 


The Unification Problem 


The unification problem arises when a function takes more than one argument with the same type 
but different effects. For instance cons is given the type: 


E ° E 5 
Va-a — a list — a list 


If a is instantiated to a function type then we need to handle the bound behaviours. To demand 
that the functions in a list all have exactly the same effect would make some programs ill-typed 
that would be well-typed without effect types. Ignoring the effect will not work, for if we extract 
and apply a function from the list, we need to know its effect. 
The unification problem is easily handled with subtyping. Consider the following two expres- 
sions: : 
Aw: out ps7: a@ a MEL unit 
in (p’,unit) 


Aw:in ps’(? : unit) : a unit 


If these two functions should both occur in a list we need to give them the same type, i.e. find an 
upper bound for their behaviour: 


a —+ unit where G = out(p, int) + in(p’, unit) 


The unification problem is not handled as elegantly using polymorphism. If we were to give 
the two expressions the same behaviour type using polymorphism we must extend each behaviour 
with a behaviour variable and unify them. This means that all functions including those with an 
empty behaviour need a behaviour variable. For example head gets the type 


Vavb-a list £22 a 


We find this solution clumsy because the type will contain behaviour variables which often will not 
need to be instantiated. In the above example b might never be instantiated. 

We are led to conclude that neither of the existing solutions will suffice in itself; subtyping 
solves the unification problem elegantly whereas polymorphism solves the argument problem ele- 
gantly. For Ainda we combine the solutions using polymorphism to describe how the behaviour 
of a function argument is related to the behaviour of the function applied and using subtyping to 
handle arguments related by the same type variable. 


4.2 Ordering Behaviour Types 


Our subtype ordering expresses that one behaviour has fewer communication capabilities than 
another. As we saw above, we need a supremum operator +. 


Definition 4.1 
We define (Bexp, <) to be the least preorder satisfying: 
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[Supremum] AsA+he Bo < Ai + Bo 


B+6B<6 
fopeuretral Ash Bs As b<h 
Bi; Be < By; By Bi + Be < By + By 
[Identity] Bs Bye Bes BP 
Bse8 cy oe 
[Unfold] ub-3 < B{pub-G/b} B{pb-3/b} < pb-B 


Moreover we need an ordering on regions: 


Definition 4.2 
We define (Reg, <) as the least preorder for which U acts as a supremum. 


Now we can define an ordering on types taking latent behaviours and regions into account. 


Definition 4.3 
We define (Typ, <) as the least preorder satisfying? : 


ert pat 
T, list < 7 list iP Ty 0S To 
Ti 1), <> 13% 14 LET, <0 a Ta 
1 em < pen if BSH ARSa A ASh 
ps pi < PSs pe if pi < pe 


4.3 Typing Rules 


Judgements are written [+ e: 7r&G and state that in type environment [ the expression e has type 
7 and when evaluated the behaviour @. Since we have strict evaluation, variables and constants have 
no behaviour (except behaviour bound in a function type), so type environments have functionality 
[': Var~+TypSch. The type inference rules are given in Table 4. 

[abs] specifies that abstraction captures the behaviour associated with the body. [app] reflects 
the call-by-value semantics; the effect of evaluating an application is the effect of evaluating the 
function to be applied, followed by the effect of evaluating the argument and finally the effect of 
the application itself. Conditionals are handled by [cond] — if the branches of a conditional have 
different behaviours, the subsumption rule is used to give them the same behaviour. [rec] is similar 
to the abstraction rule except that we have to extend the type environment with assumptions about 
the type of the recursion variable. 

We let t € TypSch denote type schemes: 


t:= 7 | Va-t | Vb-t | Vret 


We write T ~ t to state that the type 7 is an instance of the type scheme t. The type schemes of 
the constants are given by the function TypeOf (Table 5). 


‘For simplicity we have excluded some rules needed to handle wildcards, see [KJH94] 


be 


[const] 
[var] 
[sub] 


[add-hyp] 


[abs] 


[app] 


[cond] 


{let] 


[rec] 


[clos] 


Tke:t&e if r < TypeOf(c) 
CF @ Pr&e AES Ee) 


Tre: 7&6; 


———___—_—__—- if 7, < d Ai< 
Tre: t2&o en ene 


Diete: 78268 


Tig t}he:7&p if r¢*FV +(e) 


Tie nike: m&pe 


[Tk Az-e: 71 sides TLE 


[Tk e1 : 7 WS T1& G1 [+ e€9 : T28Go 
PF e1 e€2: 1&1; Go; G3 


Tre:bool&@ Fre,:7r&G6 Tee :r&p@ 
['- if e then e; else eg: T&G’; B 


[ire Cia: 7&3; I(x > Gen(T, T1)| = €2: T7835 
CF let x =e, in eg: T28&(1; Bo 


Trt ry sie T2, yo T] Fe: T2h&8 
[ rec x(y)-e : 7) ae T28LE 
Tke:7, —~ ++) —~ m&ke Thu: 7 &e 


for 1<i<m<n 
€ E€ =f 
Db <cv,--+Um> : Tm41 — +++ — ™m&E 


Table 4: Type inference rules. 
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TypeOf 


ise Sec satanlelt WEA: th cai ia lili! ne Abd cael ES mallee isaac 
Wava'-a —~ a’ —- axa’ 
< E . 
Va‘a —~ a list —— a list 


éE in(r,q) 
Vr 0-08. =) 0 Dat pa 


rd(r,a) hy 


WrVa-ps r ——> apat 


out(r, , 
VrVa-ps r —-a ate unit 


eval(r,asb 
eval YrvaVb-ps r —> (unit we a) oo Ee unit 
makeps( 


makeps Vr-unit sy ps r 


Table 5: The types of a sample of the constants. In makeps we will only instantiate r to region 
identifiers. 


The rule [let] makes use of the function Gen which generates a type scheme given a type envi- 
ronment and a type by quantifying over variables not bound in I: 


Gen(Iy7)) = let{ay,.- +, Gn, 01,---, 0m; M05. 71} = {6 | ne PVT PVT) 
in Vay... VanVb1...VomVri... WryeeT 


where « € TypVar U BehVar U RegVar. 
The type system has the property that the type is preserved during evaluation. 


Theorem 4.4 (Local Preservation) 
If te: r&B and e —~ e! thente’: r&@. 


4.4 A type reconstruction algorithm 


Our type reconstruction algorithm 7 extends the standards ideas of [Mil78] - we get a type- 
behaviour pair using the behaviour reconstruction algorithm Wg: 


T(e) =(7,@) where (9,7, 8) = Wa(nil, e) 


Here nil is the empty type environment and O is a substitution on type and behaviour variables 
found by an auxiliary unification algorithm U. 

As we have seen, the main problem in inferring behaviour types arises from the handling of 
higher-order functions. Consider e.g. a list of functions cons ( rd ps) ( cons (ps)nil); all the 
functions should have the same type 7 but not necessarily the same effect. Naively we want the 


list to have the type (a pat rdoa)+in(e.a) a) list. 


To see how this can be obtained consider the first part cons ( rd ps). This must be given the 


: d(p,a)+5 
type (a pat aM a) list —+ (a pat Als sed a) list. 


In a traditional type system cons has the type a — a list > a list. This is not adequate here, 
as the a’s are not instantiated to the same type. We therefore parameterize the a’s with behaviour 
variables: 


TypeOf(cons) = VavbVb'-a(b) —+ a(b’) list + a(b +0’) list 


se) 


This approach however, will not yield the expected type but rather (a pat rel(av) 10a a) list 
as we have to assign some behaviour to nil. 

In the presence of parameterized type variables, simple substitutions are not sufficient as a 
means of instantiation and the unification algorithm U must be redefined - only in the case of 
application should behaviour variables be instantiated whereas behaviours should be summed in 
other cases. The full details of / are described in [KJH94]. 


The type reconstruction algorithm is sound: 


Theorem 4.5 [fT e is closed and (9,7, 3) = Wg(T,e) then OT Fe: T&G 


4.5 Semantics of Bexp 


We can also give an operational semantics for the behaviour expressions. The semantics is given 
by a labelled transition system with labels: 


m € Act U {e} 


We add a new element ’(”’ to the set of behaviours to indicate termination (no \inda expression 
has this behaviour.) 

The semantics again consists of sequential and a concurrent level. The rules at the sequential 
level are shown in Table 6. Note that as the choice in ’+’ does not depend on the communication 
capabilities of a behaviour, ’+’ is the internal choice of [Hen88] rather than the ’+’ of CCS [Mil89]. 


[act] a—e A, = pt 
[idle] Dae ou G1; G2 —~ Bi; Ge 
[term] ¢« —+9 g-™ O 
Tale A, + Bp —- Ay [seq]. B: 3! — BI 


choice] i+ fe —~ 2 prey beg Ee B{yb-B/b} 


Table 6: Sequential semantics for behaviour types. 


For each element in a process space we have a configuration (@,7,) and the concurrent level 
is modelled as a multiset of such configurations. In Table 7 the rules for the concurrent part of the 
semantics are shown. [PS-elem] states that any element in a process space may evolve separately 
and [PS-uni] states that any part of the multiset may evolve. The rest of the rules state the usual 
semantics for the Linda primitives. Note that in the rules [PS-in] and [PS-rd] the regions must 
have common region identifiers in order to reflect a possible in or rd. 

The behaviour type of an expression can be seen as an abstract description of its possible 
evaluation. We define a relation between labels of the labelled transition system for expressions 
and labels of the transition system for behaviour expressions: 


Definition 4.6 We define the relation = by the following rules: 
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a ES B! 


PS-el OEit-3 Wine— (Glen bas 1 
[PS-elem] {(B,7,e)} > {(6',7, e)} 
in(p” ,r ) ; 
[PS-in] op ee my 
{Bra O7 TEAR 7 
pe gp p'Np" 40 
£(6,7,0),.7, 0) + (87,0), (7/0) 
[PS-out] = Ss 
{(6,7,p \k > 16, T; P); (Y,7', o')} 
[PS-eval] 3 evalig 1&6’) gl 
-eva TGC IE eA 
Gra Te re 
[PS-uni] PS; > PS; 


PS, PS,- PS} W PS» 


Table 7: Concurrent evaluation of behaviour types. 


in(v1,v2,v3) =< in(p,7) if Fu, : ps p&e and k v3: T&e 
rd(v1,v2,u3) = rd(p,7) if Hv, : ps p&e and b u3: T&e 
out(v;,v2) * out(p,7) if Fu, : ps pe and F vg: Tke 
eval(v, e) = eval(p,7&G) if Hu: ps p&e and ke: T&G 
makeps(v) =< makeps(p) if Hu: ps p&e 

E ne 


Using this relation the following theorem states that the semantics of behaviours indeed mimics 
the semantics of expressions: The type of an expression does not change but the effect does. 


Theorem 4.7 
If te:7T&B and e —~ e! then there exist B’ and a’ such that @ —— @', axa! andt e’: r&p’. 


As an immediate corollary of Theorem 4.7 we have that when \inda expressions evaluate, their 
associated behaviours decrease. 


Corollary 4.8 
If }e: T&G and e ee onde T&3' then there exists m <1 such that m; fi < GB. 
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An important difference from the behaviour semantics in [NN93] is that we do not use the 
ordering of behaviours in the semantics. Instead, the ordering can be recovered from our semantics 
by a simulation ordering in the sense of [Mil89]. We use @ => £’ to specify that 6 can evaluate to 


m™m 
G' using exactly one m-transition and zero or more é-transitions, i.e. == —* 


Definition 4.9 
A binary relation S C Bexp x Bexp is a simulation if ((1, >) € S implies that if 


py — B 
then there exists a 34 such that: 
fo > GB, and (h,2)€S9 
We write 3 x 3 tf (GB, GB’) ts contained in some simulation. 


Theorem 4.10 (Soundness) 
If 8 < B' then B x p. 


5 Conclusions and further work 


In this paper we present a functional language based on the Linda concept and an effect type 
system for describing concurrent behaviour. Behaviour types are rich in information about the 
causality of Linda primitives and which expressions are input and output to the process spaces. 
The semantics of behaviours shows that the behaviour type of an expression indeed describes its 
concurrent aspects. Further we have shown that the ordering on behaviours is sound with respect 
to the given simulation. An open problem at the time of writing is whether the type reconstruction 
algorithm for behaviour types is complete. We conjecture that this indeed the case. Further, it 
should be examined whether our type inference rules have the principal type property. 

Combining subtyping and polymorphism in order to solve the argument and unification prob- 
lems elegantly gives the programmer the most intuitive types (although it complicates the type 
inference algorithm for the behaviour types somewhat). The argument and unification problems 
also occur in other concurrent functional languages such as CML, Facile and LCS, and the ideas 
from the type inference algorithm for behaviour types presented here could prove fruitful in these 
languages. 

In [KJH94] we give another, sort-based effect type system. Compared to behaviours, sorts are 
less descriptive and do not capture the causality of the Linda primitives but only state which ex- 
pressions are input and output. As there is a straightforward and effective translation of behaviour 
types to sorts which preserves welltypedness, the combination of this with our type reconstruction 
algorithm for behaviour effect types provides us with a sort inference algorithm. 

Several extensions of the type system presented here can be imagined. In particular, one should 
consider the possibility of explicit polymorphism as this would allow us to communicate polymorphic 
values directly. . 
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Terminated References and Automatic Parallelization 
for State Transformers 


Peter J. Thiemann, Universitat Tiibingen, Sand 13, D-72076 Tiibingen, Germany 


Abstract 


The monadic approach to integrate first-class ref- 
erences in purely functional programming lan- 
guages suffers from escaping references and over- 
sequentialization. An extension of the type system 
by abstract types prevents references from escaping 
their scope and facilitates transforming mutable ob- 
jects into immutable ones in constant time. An en- 
hancement of the types of state transformers by ef- 
fects uncovers implicit parallelism. A program trans- 
formation is makes the implicit parallelism explicit 
so that it can be exploited by a parallel implementa- 
tion. 


Keywords: state monad, first-class references, ab- 
stract types, implicit parallelism. 


1 Introduction 


Pure lazy functional programming languages per- 
form all computations by function application. They 
do not have an implicit concept of mutable state 
and hence do not suffer from side effects. However, 
the lack of assignments and mutable data structures 
makes it difficult to formulate efficient algorithms for 
certain problems. 

Fortunately, many algorithms use large data struc- 
tures like arrays or graphs only in a single-threaded 
manner: after an update to the data structure, its 
old version is never referenced again. Such a data 
structure can be updated destructively (by assign- 
ments) without introducing side effects. Whenever 
an assignment is executed, the assignment operation 
has the unique reference to the modified data struc- 
ture and no other part of the program has access to 
it. Recent approaches to augment purely functional 
programming languages with mutable data struc- 
tures have introduced abstract datatypes which en- 
sure single-threaded handling of mutable data struc- 
tures. Among them is the monad of state transform- 
ers (state monad, for short) [Wad90, Wad92] which 
encapsulates the propagation of a state through a 
whole computation. It provides proper sequencing 
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of I/O operations [PW93] or lazy computations with 
mutable variables and arrays [Lau93]. In this ap- 
proach, references to mutable variables and arrays are 
first-class values which are created and manipulated 
by primitive operations of the monad. 

If the state monad is used to provide proper se- 
quencing of assignment operations, only one incarna- 
tion of the state can be active in a given program 
without the risk of introducing side effects. To see 
this, suppose a reference created in one incarnation of 
the state monad is allowed to be returned as a result 
(and thus to “escape” ). If that is possible, an expres- 
sion e can be constructed which passes the reference 
to two different incarnations of the state monad such 
that the value of e depends on the evaluation order. 
Thus side effects can be introduced unless suitable 
provisions are taken. 

For performing I/O it is perfectly acceptable to 
have a single global incarnation of the state monad. 
For performing computations involving references, 
having just a single incarnation sequentializes the en- 
tire program. It is therefore preferable to have local 
incarnations of state transformers which work inde- 
pendently on local states. 


Our Contribution The present work is concerned 
with the use of state transformers to provide proper 
sequencing for assignment operations. 


1. We propose to use a restricted form of existential 
types (downward abstract types) for the propa- 
gated state of state transformers. Each incarna- 
tion of a state transformer is provided with its 
own unique identity through its abstract type. 
References are first-class objects confined to the 
local scope of a single incarnation of a state 
transformer. Programs where a local reference 
may be returned as a result are rejected by the 
type checker. 


2. State transformers can construct immutable ob- 
jects: after a mutable object is allocated and 
changed by assignment operations its final ver- 
sion can simply be declared immutable and re- 


leased. This is only safe if there is exactly one 
live reference to the object. Upward abstract 
types, the dual to downward abstract types, can 
ensure the required uniqueness property. They 
are used to type terminators which delimit the 
life-time of a mutable object and may thus trans- 
form it into an immutable one without copying 
it. 


3. State transformers impose an arbitrary order on 
their primitive actions, namely their order in 
the program text. When multiple mutable ob- 
jects are manipulated simultaneously this order 
is often overly conservative. We offer a program 
transformation that uncovers the inherent paral- 
lelism by grouping the primitive operations ac- 
cording to the mutable objects that they act on. 
The transformation relies on an effect annota- 
tion of the type constructor for state transform- 
ers. The effect annotation describes the use of 
mutable objects in the local state. 


The mechanism of upward and downward abstract 
types is quite similar to existentially quantified types. 
There is a type reconstruction algorithm [Thi93] 
which handles them like nullary type constructors 
(cf. the Skolem type constructors used by Laufer and 
Odersky [LO92] to model abstract types by existen- 
tially quantified types as pioneered by Mitchell and 
Plotkin [MP88]). However, there is no special syntax 
to introduce a value with an abstract type and type 
declarations are required to introduce abstract type 
variables. 

Notice that the effect annotation and thus the pro- 
gram transformation to expose parallelism is also us- 
able with the solution to the encapsulation problem 
of Launchbury and Peyton Jones [LP94]. The trans- 
formation also sheds some light on how to program 
communicating processes with local state in a lazy 
parallel functional language. 


Outline of the Paper Section 2 briefly introduces 
state transformers and their application to sequence 
assignments. An example which illustrates the dan- 
ger of escaping first-class references is given in Sec- 
tion 3. An informal outline of our solution follows. 
Section 4 introduces the concept of terminators which 
can be used to transform mutable objects into im- 
mutable ones, describes the necessary modifications 
to the type system, and demonstrates their use with 
an example. Section 5 analyzes the effects of state 
transformers and defines a transformation to separate 
independent parts of state transformers. Sections 6 
and 7 define different ways to run the separate parts 
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independently and possibly in parallel. Finally, in 
Section 8, we discuss what to do when a clean sepa- 
ration in independent parts is not possible. Section 9 
discusses related work and Section 10 concludes. 


2 State Transformers 


A state transformer [Wad90, Wad92] is a function 
which maps an initial state to a result paired with a 
final state. Its type definition is: 


type ST state value = state -> (value, state) 


This declaration introduces the type constructor ST 
with two parameters state and value with the obvi- 
ous meanings. Here and throughout the whole paper, 
we make liberal use of Haskell [Has92] syntax in ex- 
amples. The basic operations on ST s v are defined 
as follows. 


result :: v -> ST sv 
result x = As -> (x, s) 


(>) :: STs v -> (v -> STs w) -> ST sw 
m D> g = As -> let (x, s’) =ms ingxs’ 


result x specifies a state transformer which does not 
change the state and returns x immediately. The bind 
operation > accepts a state transformer m and a func- 
tion g from results of m to state transformers. m > g 
is a state transformer which first runs m with result x 
and then runs the state transformer g x obtained by 
applying g to x. result is a left and right unit with 
respect to > and D is associative, hence ST s visa 
monad, for any s. We call an executing incarnation 
of a state transformer a (state) thread (cf. [LP94]). 
A value of type ST s v is a (state) action. From 
the definitions we see that the state component is 
propagated through the whole computation without 
duplication, therefore the state is single-threaded. 

Since result and > handle the state in a single- 
threaded manner it is safe to enhance ST with as- 
signment operations to the state. A state action can 
be executed with the function exec which accepts an 
initial state value and an action to produce the re- 
sult after running the action on the initial state (fst 
returns the first component of a pair). 


exec :: 8s -> STs v->v 
exec init action = fst (action init) 


Peyton Jones, Wadler, and Launchbury [PW93, 
Lau93] have suggested a more powerful way to use 
the sequentialization imposed by state transformers. 
They enhance state transformers by primitive actions 
to perform an I/O operation, create a reference, read 
a reference, or assign to a reference. The propagated 
state is only used to fix the order of their execution. 


To execute such a computation it suffices to apply it 
to an arbitrary (non-bottom) initial state, for exam- 


ple () of type (). 


run :: ST QO v->v7 
run action = exec () action 


With this knowledge a signature for primitive oper- 
ations on references can be defined [Lau93]. In the 
following, datatypes whose name ends with a ! de- 
note references to mutable objects. In the signature 
below, Ref! is the type of references to mutable vari- 
ables. 


type Ref! v -- abstract type of references 
type Seq v = ST () v 


ertRef :: v -> Seq (Ret! v) 
getRet :: Ref! v -> Seq v 
updRef :: Ref! v -> v -> Seq () 


crtRef creates a new variable, getRef reads its con- 
tents, and updRef assigns to it. To ensure proper 
sequencing the functions getRef r and updRef r v 
must be strict in the propagated state’, for some r 
:: Ref! b and v :: b, and also in their reference 
argument r, but not in the assigned value v. A more 
precise operational semantics in the form of graph 
rewriting rules is given in Appendix A. The execu- 
tion of updRef r v actually assigns the value of v to 
the variable referenced by r. Two examples are given 
for computations with references: an action incrRef 
which accepts a reference to a number and updates it 
with the incremented value and an action swap which 
exchanges the values of two references. 


incrRef :: Ref! Int -> Seq () 
incrRef r = getRef r D> Av -> updRef r (v+1) 


swap :: Ref! v -> Ref! v -> Seq () 
swap rs = | 
= getRef r DAv -> getRef s DAw -> 


updRef r w DA_ -> updRef s v 


3 Encapsulating References 


Since updRef is a real assignment operation, side ef- 
fects can be introduced through run as follows. - 


Example 1 


let r = run (crtRef 0) 
a = incrRef r D> A() -> getRef r 
in (run a, run a) 


‘The strictness can be made explicit at the source level by 
using an algebraic datatype data D x = D x as the state type 
as in [PW93, LP94]. Since that complicates the types we just 
state the required strictness. 
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By referential transparency, the value of this expres- 
sion should be a pair of equal numbers. However, 
depending on the context its value is either (1,2) or 
(2,1). This side effect is due to the reference r :: 
Ref! Int which escapes from its creating thread run 
(crtRef 0) and is used in other threads. 

In order to avoid escaping references we change the 
type of run so that the type of the propagated state is 
abstract. The type is specified with a downward ab- 
stract type (to be defined below) which is abstracted 
with the quantifier |. The net effect is that every 
thread has is own unique state type. 

STs v->v 


run 3s 4isut 
As the all-quantification, the quantifier | is also only 
allowed at the top-level. The type system still distin- 
guishes between types (without quantification) and 
type schemes. As in the ML type system the rules 
for abstraction and application only apply to types. 

Furthermore, the type of the manipulated refer- 
ences must be linked to the state of the creating 
thread. This is done by adding a type variable s 
to the type of references. The signature is revised as 
follows. 


type Ref! sv 

-- abstract type of references 

-- to variables of type v 

-- created by a thread with state type s 


crtRef :: v -> ST s (Ref! s v) 
getRef :: Ref! s v -> ST sv 
updRef :: Ref! s v -> v -> STs () 


Downward abstract type variables (quantified with |) 
are a restricted form of existentially quantified type 
variables and share their introduction and elimina- 
tion rules: 


AH eel axe 
AkFe:tlae y] 


Ake:tlar 1] 


Pe Ot (LE) 


(11) 


In the elimination rule, y is a fresh nullary type 
constructor which does not occur elsewhere. 

If we use the above type |s . ST s v -> v for 
run, Example 1 is not well-typed anymore: the ref- 
erence r has type Ref! y Int, hence a has type 
ST y Int. Moreover, the occurrences of run in the 
last line have types ST y’ Int and ST y” Int, for 
y' #y and y” #y, therefore the applications run 
a are not well-typed. But existentially quantified 
type variables are not enough: a function of type 
Vs,v,....(ST s vv) —... can take run as a pa- 
rameter and reconstruct the situation in Example 1 
in its body (see [Thi93]). It follows that passing run 


as a parameter must be ruled out?. The following 
tule ensures this. 


Rule 1 In the derivation of a typing judge- 
ment A F- e: T no generic type variable « 
may be instantiated with a type containing 
a downward abstract type which is intro- 
duced “to the right” of a. 


In this context, “left” arbitrarily denotes the func- 
tion judgement of the application rule, and “right” 
denotes its argument judgement. Passing run as a 
parameter is impossible: suppose for a contradiction 
that 


At-run: VWv.ls.STsv—ov 
Afrun: [sSTstTOT 
Afrun:STatoTt 
AE f rune 


Ab fit! at" 


is a valid derivation. The downward abstract type a 
contained in the type instance of run must also occur 
in t’. But acannot occur in the assumption A, as any 
application of the introduction rule creates a unique 
downward abstract type. Hence the derivation for 
At f:t’ 47” must contain some instantiation of a 
generic type with a. Since Rule 1 is violated by this 
instantiation the above derivation cannot be valid. 

However, abstract types can travel from left to 
right in a derivation tree, as illustrated by the fol- 
lowing example. 


Example 2 The expression run (result 1) (which 
is a prototype of a practically useful expression) is 
legal since the derivation in Fig. 1 is valid. We only 
have to check our rule at the point where result is 
introduced. But a has been introduced to the left of 
result in the proof tree so the rule is not violated. 


The somewhat intuitive Rule 1 can be checked in 
an implementation in a straightforward way. The 
type checking algorithm creates new type variables 
(and new abstract types) by threading a name sup- 
ply through all its recursive invocations. Typically, 
the algorithm visits the function part of an applica- 
tion before its argument parts. The names assigned 
in this manner do reflect an inorder traversal of the 
derivation tree. Therefore, the check if some a was in- 
troduced to the left of the current node of the deriva- 
tion tree boils down to compare the name of « with 
the current name supply. The formalization of this 
is rather technical and details on it are found in a 
technical report [Thi93]. 


?This effect is achieved in [LP94] by giving run the rank-2 
type Va.(VB.STB a) 4 a. 
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4 Introducing Terminators 


Arrays in pure functional languages are usually 
monolithic (the contents cannot be defined incremen- 
tally) and immutable (the contents cannot be mod- 
ified). In Haskell, they are constructed with a func- 
tion array which accepts a size and a list of index- 
value pairs and returns an immutable array which 
associates the indices to their respective values in the 
list. This former primitive function can now safely 
be written using a state thread: allocate a mutable 
array, fill it using assignment operations, and let it 
escape from its creating thread. But the typing of 
run prevents exactly that. Launchbury and Peyton 
Jones [LP94] have therefore introduced the operation 


freezeA :: Array! state v -> ST state (Array v) 


(ignoring the index which is another parameter of 
Haskell’s Array datatype) such that freezeA a is 
strict in its state argument and in a and provides 
the proper retyping. The implementation of freezeA 
cannot simply be a strict version of result which 
declares its argument immutable: a full copy of the 
argument array must be performed. Otherwise side 
effects may be introduced if the array is subsequently 
assigned to. 

If the argument array of freezeA is the unique last 
reference to the array it is safe to omit the expensive 
copy operation. A further change in the signature 
and the type system can be used to obtain the neces- 
sary uniqueness information. The idea is to introduce 
terminators for references. A terminator is an action 
that takes a reference as an argument. Its typing 
ensures that the reference cannot be used after its 
terminator action has been executed. The type of 
a terminator contains an upward abstract type which 
behaves dually to downward abstract types: 


Rule 2 In the derivation of a typing judge- 
ment A F e: T no generic type variable « 
may be instantiated with a type containing 
an upward abstract type which is introduced 
“to the left” of «x. 


The introduction and elimination rules for upwards 
abstract types are the same as for downward abstract 
types. 

To make use of terminators the abstract type 
Array! of references to mutable arrays is augmented 
with a third parameter. The parameters are term for 
its terminator type, state to link it with its creating 
state thread, and value for the type of the array ele- 
ments. The signature has to be changed according to 
Fig. 2. The intended semantics of the operations is 
specified as follows. Let ar :: Array! t s v,i:: 


AF run: VW.ls.STsv—-v 
AFfrun: |s.STs Int > Int 
AF run: ST a Int > Int 


AF result: Int — ST a Int 


AF result: Vs,v.v—73STsv 
Ac Lt 
AF result 1: STa Int 


AF run (result 1): Int 


Figure 1: A legal derivation 


type Array! term state value -- abstract 
createA :: Int -> v 

-> ST s (Array! t s v) 
selectA :: Array! t s v -> Int 

-> ST sv 
updateA :: Array! t s v -> Int -> v 

-> STs () 
freezeA :: Tt. Array! t s v -> ST s (Array v) 
run ; aelis<) STi seven-day 


Figure 2: Signature for mutable array operations 


Int and x :: v. The action createA i x allocates 
a mutable array with range [0 .. i-1] with all en- 
tries initialized to x. The ith entry of array ar is 
obtained with selectA ar i. The ith entry of ar is 
updated to x with updateA ar i x. Both selecta 
and updateA must be strict in the propagated state 
s, the array reference ar, and the index i. The action 
freezeA with the above type serves as a terminator 
for mutable arrays. freezeA ar captures the muta- 
ble array ar and returns an immutable array with 
the same contents. The typing ensures that ar is the 
unique last reference to the mutable array. Its imple- 
mentation runs in constant time since the argument 
array need not be copied. 

As an example we provide an implementation of a 
function invert which accepts a permutation 7t in the 
formof perm :: Array Int (where perm!!i =7(i), 
!! is Haskell’s array indexing operation) and returns 
the inverse permutation 77! in a newly allocated ar- 
Tay. 


invert :: Array Int -> Array Int 
invert perm 
= let n = range a 
help ia 
= if i<n then 
updateA a (perm!!i) i DA_ -> 
help (iti) a 
else 
result () 
bot = bot 
in run (createA n bot > Aa -> 
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help 0 aDA_ -> 
freezeA a) 


In a similar way, it is possible to introduce mutable 
lists and heaps and perform arbitrary computations 
on them. Once the desired structure has been con- 
structed the object can be “frozen” as a whole into 
an immutable object. Notice, that the structure can 
be circular which makes a copy operation (thus a safe 
freeze without a terminator type) prohibitively ex- 
pensive. 


5 Separating Effects 


The primary reason for introducing state transform- 
ers is to keep read and write operations to the state 
in the correct order. However, the actual sequence 
in which actions are executed depends on an artifi- 
cial data dependency constructed from the program 
text. It surely reflects the desired execution order 
but it is conservative as it can only model a linear or- 
der on assignment operations whereas the actual data 
dependency need only be a partial order. This hap- 
pens, when a single thread performs computations 
involving references to multiple mutable data struc- 
tures, for example, a mutable array and a couple of 
mutable variables. 

The transformation presented below extracts linear 
dependency chains from a state action and also pro- 
vides for a way to run them independently, possibly 
in parallel. The extracted slice encompasses exactly 
those actions which operate exclusively on a fixed set 
of references. When there are interdependencies the 
necessary synchronization can be provided, too. 


5.1 Effects for State Transformers 


But how can the compiler determine which action 
belongs into which slice? The type ST s _ v of an ac- 
tion a only describes the possible value of a. It does 
not describe which variables are read or written by a. 
We need a description of the effects of a. Every result 
due to the evaluation of an expression which is not 
reflected in its value is called an effect. Therefore, an 
effect system [LG88] relates an expression not only to 


its type but also to its effects. Function abstractions 
delay the effects of their body until they are applied 
to an argument. Hence, function arrows are anno- 
tated with their latent effects, which may happen 
during the application of that function. The orig- 
inal motivation to introduce effect systems was the 
implementation of impure strict functional program- 
ming languages on parallel machines. Effect analysis 
is used for allocating computations to processors and 
for deciding in which local memory a variable should 
be allocated. 

In the present case, effects can only occur when 
a state transformer is executed. The only function 
arrows which must have an effect annotation are hid- 
den in the state transformer type ST s v = 8 -> 
(v, s). Thus, we annotate the type constructor ST 
with an effect description M. The effect description 
M for an action a is the set of terminator types of 
the references that a operates on. If the type t is in 
M then a reads, writes, or creates a reference of type 
Ref! t s v, for some s and v. The annotations for 
the primitive actions are as follows: 


crtRef :: vy -> ST't' s (Ref! t s v) 
getRef :: Ref! t s v -> sTt sv 

updRef :: Ref! t s v -> v -> st! sy 

result :: v -> st’ sv 

(bp) 2: °SstT™ so v.=> (vy => ST's _8)) => STYUN's 8 


ertRef, getRef, and updRef all have an effect on 
the variable terminated by t. The primitive action 
result does not have any effect. The combination 
a > Ax -> b of an action a with effects M and an 
action b with effects N is an action with effects MUN. 
Furthermore there is a subtyping rule which states 
that a :: STM s vimpliesa :: STM’ sg v for any 
M’ > M. These definitions suffice to determine the 
least effect of any given action. For a of type STN s 
v we set least-effect(a) = M where M is the smallest 
set of types such that a has type ST” s v. 


5.2 Slicing Actions 


Let T be the set of terminator types of a given set of 
references. Once the effect annotation of an action is 
known, it can be divided in two subactions or slices 
according to T. One slice comprises all those prim- 
itive actions which operate of references in T, while 
the remaining actions are collected in the second slice. 
The effect-guided program transformation to extract 
the slices is presented below. 

There are some critical issues in the design of the 
transformation. 


e The separation of the slices drags variables out of 
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their binding scope. The values of these formerly 
bound variables must be made available. 


This is achieved by having each slice return the 
values of all bound variables in a tuple. These 
tuples are then fed back into the other slice with 
a suitable fixpoint operator. 


e The result of the original action is now (part of) 
the result of one of the slices. It must be recorded 
which slice returns the original result. 


The laziness properties of the original program 
should be maintained. Non-trivial expressions 
should not be duplicated. However, they can- 
not be evaluated in one of the slices since that 
introduces unwanted dependencies. 


Sharing of non-trivial expressions is achieved by 
binding their values to variables with newly in- 
troduced let-expressions. These lets are then 
lifted out of the slices, so that their scope in- 
cludes both. 


The transformation need not treat abstractions 
and simple constants, they are ruled out as their 
type can never be ST s v. Every other expres- 
sion must be dealt with. However, in this exposi- 
tion we leave function applications and recursion 
alone, while compound actions (with a top level 
>), conditionals, and let-expressions are split. 


e There might be actions with least effect M such 
that neither M C T nor MNT =@ holds. 


For the moment we assume that all actions can 
be decomposed (by our transformation) into ac- 
tions a where either M C T or MNT = @ (M is 
the least effect of a). Later on, in Section 8, we 
will drop that assumption. 


The transformation makes use of an auxiliary func- 
tion split of type 


P(Type)x AxAxA - {1,2}xAxAxAx Binder xA 


where Type is the set of type expressions, A is the 
set of expressions (see Appendix A), and Binder is 
the set of binders, 2.e. lists of pairs x = e with x a 
program variable and e € A. Binders B occur in the 
definition part of a let-expression: let B ine. 

In the specification of the transformations, [ 
quotes | and ( unquotes ) are used to distin- 
guish target program syntax from the meta level. 
The application splt(T,[()],[()],a) yields a tuple 
(i, W1, W2, B, r1, T2) where 


e T is the set of types-of-interest, the terminator 
types of the references the actions on which are 
to be extracted, 


e a is the original action expression of type ST s 
v, for some type v, 


e i€ {1,2}such that r; is the action delivering the 
final result of a, 


e W; and W?2 are nested tuples which contain the 
bound variables of r; and T2, 


e B is a list of binders of the form X = A, which 
are used to capture shared computations, 


T} is the extracted slice of a containing all actions 
which are annotated by a subset of T, and 


T2 is the slice with all remaining actions. 


The function split maintains the following property 
for a of type ST’ s v: ifi =1 then 


tT) 2 STM" 5 (v, type(W1)) T2 2 ST™M2 5 type(W2) 


otherwise (if i = 2) 


r12ST™" 5 type(W}) T2 2 STM2 5 (v, type(W2)) 
where M; C T and Mz2NT =9. Each slice returns 
the values of its bound variables as a nested tuple 
and one of them additionally returns the result of the 
original action. 

In a preprocess to split, the action a is transformed 
such that all bend operations occur in the form a D> 
Ax.a’, all bound variables have unique names, and in 
all expressions of the form if b then a; else a2 the 
condition b is just a variable. This is achieved by 
N-expansion, a&-conversion, and by introducing auxil- 
iary lets. 

The rules are given in order of priority as in a real 
functional program. 

The first rule (rule (1) in Fig. 3) for split is con- 
cerned with normalizing binds. Repeated application 
of the rule isolates a single atomic action on the left- 
hand side of a top-level >. The rule is obviously 
correct since > is associative. 

The following rules (2) and (3) should not be used if 
the argument action has least effect M where M C T 
or MNT = 9. In these cases nothing is gained by 
splitting the action. Rule (7) applies instead. 

Rule (2) handles the case where the top-level action 
is enclosed in a let-binding let x = e ina. In 
principle the computation of e could be assigned to 
one of the slices. But it is clearly undesirable to do 
so because unwanted dependencies between the two 
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slices might be introduced. Therefore the binding 
x = e is appended to the list B of binders and lifted 
to the top-level. Now e can be computed on demand 
by either of the slices and its value is shared by both. 

If the top-level expression is a conditional expres- 
sion, for example if b then a; else az, aconditional 
expression must be generated in both slices. Since 
b is a variable (by virtue of the preprocessing step) 
it can be duplicated without duplicating computa- 
tion. The complicated code in the rule stems from 
the fact that both branches of a conditional must have 
the same type. Hence the variable bindings of each 
branch must also be returned by the other branch. 
The bound variables of the branch which is not taken 
are undefined, but never referenced, so that will not 
cause problems. See rule (3) in Fig. 3. 

If the left-hand operand of the top-level > is a let- 
expression, the binding is lifted to the top-level and 
then handled by rule (2). Pushing the let outward 
does not capture any free variables since distinct vari- 
able names have been assumed. The corresponding 
tule is rule (4) in Fig. 3. 

If the left-hand operand of the top-level > splits 
but is not of the form a > Ax.a’, it must be split re- 
cursively and then prepended to the outcome of the 
transformed right hand operand. This case applies, 
for example, when the left-hand operand is a condi- 
tional expression. The corresponding rule (5) is found 
in Fig. 3. . 

Rule (6) in Fig. 3 treats the case where the left- 
hand operand of the top-level > cannot be decom- 
posed any further. It must be examined for annota- 
tion with a subset of the types-of-interest T and as- 
signed to one of the slices. The bound variable, which 
might be referenced in the other slice, is added to the 
respective V. The remaining case, where M Z T and 
TOM £49, is covered in Sec. 8. 

The final action a (without top-level >) must be 
treated slightly different, since it must be registered 
which slice delivers the final result. Furthermore B is 
initialized to the empty list of binders ¢. The corre- 
sponding rule (7) is shown in Fig. 3. 


6 Extracting Terminated Computations 


So far, if we are given a set T of types-of-interest 
(terminator types) and an action a we can slice a in 
two independent actions a; and az. It remains to 
establish the means to run them independently and 
to feed back the values of the bound variables of ay 
to a2 and vice versa. 

The first goal is met with the operation 
interleave :: ST s v -> ST s v [PW93, LP94]. 


— (a2)) > Gy 3)]) 


split(T, Vi, V2, [((a1) & A(x) 
3))]) 


= split(T, Vi, V2, f(a) > A(x) > ((a 2) > 


split(T, Vi, V2, [Let (x) = (e) in (a)]) 
let (i, W1, W2, B, 11, T2) = split(T, Vi, V2, (a)) 


in (i, W1, W2, [(B); (x) = (e)], 71, T2) 


split(T, Vi, V2, [if (b) then (a) else (a2)]) 
= let (i,W), W2, B,11, 72) = splat(T, [()], [0], (a1)) 
(i’, Wj, W3, B’, 14,75) = splat(T, [0], (OT, (a2)) 
in ifi=1 andi’ =1 then 
let z be a fresh variable in 
(i, [ (2, (Wi), (W4),(V1)))]6 [((W2)s (W3), (V2))T), 
[if (b) then (11) b> A(z, (W))) 
result (z, ((W1), (Wj), (V1))) 
else (rj) > A((Wj)) 
result (z,((W1),(W7),(V1)))I, 
[it (b) then (r2) > ((W3)) 
result ((W2), (W535), (V2)) 
else (75) > A((W3)) 9 
result ((W2), (W5), (V2)) )) 


else ... 


split(T, Vi, V2, [(Let (x1) = (e) in (a1)) > A(x2) - (a2)]) 
= split(T, Vi, V2, [let (x1) = (e) in ((a1) B A(x2) > (a2)])) 


split(T, Vi, V2, [(a1) > A(x2) as (a2)]) 
let (i, W1, W2, B, 11, r2) = split(T, [()], 0], a1) in 


in (i, W4, W4, [(B’);(B)], (r1) & AC(x2), (W4)) 
else ofi=2 then ... 


splat(T, Vi, V2, [(a1) & A(x) > (a2)]) 
= let M = least-effect(a;) in 


if MCT then 
let (i, Wi, W2, B, 11, r2) = splee(T, [( (x), ey 1; V2,.02) 


tn (i,W1, W2, B, [(a1) & A(x) > (11)], T2) 


else if TIM =9 then 
let (i, W1, W2, B, 1, r2) = splat(T, Vi, [((x), (V2))], a2) 


tn (i,W1, W2, B, 11, [(a1) & A(x)  (T2)]) 


splat(T, V;, V2, a) 
= let M = least-effect(a) in 
if MCT then 
(1, Vi, V2, €, [(a) & Az > result (z,(V}))], [result (V2)] 


else if T. M=@ then 


(2, Vi, V2, €, [result (V1)], [(a) > Az > result (z, (V2))]) 


Figure 3: Rules for split 
ie 


fiz then 
let (i’, Wj, W3, B’, 7}, 75) = splet(T, [((x2), ((W1), (V1)))], [((W2), (V2))], a2) 
— (14), (72) & A(W2) > (13)) 


(1) 


(2) 


(5) 


It runs its argument action a independently (possi- 
bly concurrently) from the following computation by 
ignoring the final state of its argument: 


interleave a 
= \s -> let (x’, s’) = as in (x’, 8) 


The duplication of the state s in interleave is po- 
tentially dangerous. In interleave a > Av -> a? 
the action a as well as the action a’ can read and 
write the same variables. However, if a only oper- 
ates on terminated references and includes their ter- 
minators the subsequent action a’ cannot have ac- 
cess to them and hence cannot interfere with the in- 
terleaved action. Thus interleaving computations on 
terminated references is safe. 

Intertwined in a single action the slices communi- 
cated via variable bindings. Fortunately, split col- 
lects the bound variables of the slices in V; and V2. 
The necessary feedback operation from one slice to 
the other can be achieved with the combinator fixST 


({LP94]), defined as: 


fixST :: (v -> STs v) -> ST sv 
fixST f = As -> let (x’, s’) = f x’ s in (x’, 8’) 


Using fixST and interleave the main transforma- 
tion is specified as follows 


extract(T, a) 
= let (i, Vi, V2, B, 1, r2) = splet(T, [()], [0], a) an 
fiz then 
[fixST( Az 
Let (21,(V1),(V2)) = Z0;(B) in 
interleave (r;}) b A(z1,(V1)) 
(r2) > XV2) ~ 
result (21, (V1), (V2))) 
D> A(z, (Vi), (V2)) — result z1| 
else 
[fixST( Az 
let (22, (V1), (V2)) = Zo0;(B) in 
interleave (r}) D A(V1) > 
(t2) & A(z2,(V2)) > 
result (z2, (V1), (V2))) 
> A(z2, (V1), (V2)) — result z2| 


The application of fixST serves to equate the ar- 
gument of the final result (z;,(V1),(V2)) with the 
argument Zo of its argument function. Since the final 
result contains the values of all bound variables, these 
values are available in the whole body of fixST’s ar- 
gument function: the binders B, r}, and rz. The 
transformed expression depends crucially on the ir- 
refutability of the pattern binding (z),(V1),(V2)) = 
Zo. Otherwise the required cyclic bindings cannot be 
established. 
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6.1 Example: Lazy File Read 


The motivating example of [PW93, LP94] for 
interleave is the implementation of lazy file read. 
The state monad cannot only be used to ensure cor- 
rect sequencing of actions on references, but it can 
sequence I/O actions as well. Usually a more strict 
version thenIO of the bind operator is employed for 
I/O. thenIO is strict in the propagated state and 
forces the immediate execution of its argument ac- 
tions, since there is no point in delaying I/O actions. 

A typical subset of primitive I/O actions is 
openFile :: String -> ST s (Fildes t s) 
(opens a file and returns a file descriptor), eof :: 
Fildes t s -> ST s Bool (tests for end of file), 
readChar :: Fildes t s -> ST s Char (reads 
a character), and closeFile :: Fildes t s -> 
ST s () (closes a file). An action which reads the 
contents of a file into a list of characters can be 
written as follows. 


readFile :: String -> ST s String 
readFile fname = openFile fname > Afd -> 
let readContents 
= eof fd > Adone -> 
if done then 
closeFile fd ‘thenI0‘ A_ -> 
result [] 
else readChar fd pb Ach -> 
readContents > Arest -> 
result (ch:rest) 


readContents > Acont -> 
result cont 


In the program fragment readFile f > Achs -> 
next_action, the first read or write action in 
next_action requires the complete execution of 
readFile f due to the sequentialization induced by 
bind. That is, the entire file f is read before any other 
I/O action can take place. Reading the contents of f 
lazily on demand would be much more efficient. 

Let us introduce a terminator termFile of type 
Tt. Fildes t s -> ST s (), which is strict in the 
file descriptor of type Fildes and in the state, and 
place it right in front of the final result cont, as in: 


readContents > Acont -> 
termFile fd p A_ -> 
result cont 


Let t be the terminator type of fd (from the appli- 
cation termFile fd). Applying the eztract transfor- 
mation with T = {t} to the body of readFile yields: 


readFile fname = 
fixST (Az0O -> 
let (cont, fd) = zO in 


let readContents =... 
in interleave ( 
openFile fname D> Afd -> 
readContents > Acont -> 
termFile fd DAL -> 
result cont 
) Dp Acont -> 
result (cont, fd) 
) > ACcont, fd) -> 
result cont 


7 Extracting Unterminated Computations 


Computations can be extracted from a state ac- 
tion even if they are not terminated. However, 
interleave cannot be used to parallelize them, since 
subsequent actions depend on the outcome and effects 
of both slices. Therefore, we introduce a combinator 
fork which accepts two state actions and executes 
them independently. 


fork :: ST s v -> ST s w -> ST s (v, w) 
fork acti act2 s 
= let (x1, s1) = acti s 
(x2, s2) = act2 s 
in ((x1, x2), mergeStates si s2) 


The function mergeStates has type a -> a -> a 
and is strict in both arguments, such that a demand 
on the output state of fork act1 act2 causes a de- 
mand on the output states s1 and s2 of both acti 
and act2 which in turn forces their execution. The 
fork operator as defined above enables the inter- 
leaved execution of its argument actions act1 and 
act2. As in the case of interleave, the use of fork 
is potentially dangerous. It can only be guaranteed 
to be correct if the argument actions do not interfere, 
1.€. acti does not read references that are written to 
by act2, acti does not write references that are read 
or written by act2, and vice versa. Of course, our 
transformation only introduces safe forks since it is 
only applied to slices which operate on disjoint sets 
of references. 

In a parallel implementation the let in the defini- 
ton of fork could be replaced by a letpar construct 
which starts the evaluation of its binders in parallel. 

Notice that fork as defined above behaves different 
to the fork operator in recent work of Jones and 
Hudak [JH93]. Their fork only interleaves actions if 
they make use of explicit communication primitives. 

The transformation becomes pleasingly symmetric 
using fork, as shown in Fig. 4. As an example for 
an application of ertract’ consider the function swap 
which creates an action which exchanges the contents 
of two references. 


swap :: Ref! tis v -> Ref! t2 s v -> STs () 
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swap rs = getRef r Db Av -> getRef s > Aw -> 
updRef rw DA_ -> updRef s v 


The state monad sequentializes swap too much (albeit 
on a trivial scale): reading the references can be done 
in parallel, as well as updating them, as long as no 


reference is overwritten before it is read out. The 
most liberal order looks like this: 

getRef r getRef s 

updRef r vs updRef s vr 


Application of eztract’ to the body of swap yields 
(after some simplification): 


pswap rs = 
fixST (Azo -> 
let (vr, (z2, vs)) = z0 in 
fork 
(getRet r > Avr -> 
updRef r vs D A_ -> 
result vr) 
(getRef s > Avs -> 
updRef s vr > Az2 -> 
result (z2, vs))) 
> ACL, (z2, _)) -> result z2 


While the above action pswap works correctly even 
if its arguments reference the same mutable variable, 
this is not true in general. As an example consider 
the following action munge which performs the assign- 
ment (r,s) :=(r+s,r—s). 


munge :: Ref! tis v -> Ref! t2 s v -> STs () 
munge r s = getRef r > 
Av -> getRef s > Aw -> 
updRet r (v+w) > 
A_ -> updRef s (v-w) 


munge can only be parallelized along the lines of swap 
if r and s cannot be aliases for the same variable. 
Fortunately, the terminator type of the involved refer- 
ences indicates aliasing: when r and s may be aliases 
of one another their terminator types are equal. 

It turns out that terminator types can be kept dif- 
ferent by adding inequation constraints of the form 
a # B to the types of state transformers. For exam- 
ple, the type of a parallelized munge would be 


Ref! ti sv -> Ref! t2 sv 


Tfetioas @2t2 


pmunge :: 


With this type we could split pmunge as follows: 


extract’ (T, a) 


ifi=1 then 


let (i, Vi, V2, B, T1, 72) = split(T, fO], fOl, a) in 


[fixST(Az 3 let ((21,(V1)), (V2)) = 20; (B) in 
fork (r1) (r2)) 
> A((z1,(V1)), (V2)) result 21] 


else 


[fixST (Azo — let ((V}), (z2, (V2))) = 20;(B) in 
fork (r1) (T2)) 
> A((V1), (zz, (V2))) 3 result zz] 


Figure 4: Extraction for unterminated references 


pmunge rs = 
fixST (Azo -> 
let (v, (z2, w)) = z0 in 


fork 
(getRef r > Av -> 
updRef r (v+w) DA_ -> 
result v) 
(getRet s D> Aw -> 


updRef s (v-w) D> Az2 -> 
result (z2, w))) 
DAC, (z2, _)) -> result z2 


Another modification of the type checker helps to 
enforce the inequation constraints: they must be 
checked whenever the unification algorithm extends 
the current substitution. 


8 Synchronization 


However satisfactory the transformation works in the 
preceding example, it is not yet complete in general. 
There is still a synchronization problem: what hap- 
pens if an action in the extracted slice refers to a 
reference manipulated by the remaining slice? An 
example is the action swap r s where r “belongs” 
to one slice and s to the other. swap r s cannot 
simply be assigned to one of the slices since doing 
so can introduce side effects. The solution is to syn- 
chronize the slices such that swap r s can only be 
executed when all preceding computations that are 
assigned to the other slice are done and that the 
other slice can only continue after swap r s has been 
executed. To achieve the synchronization, a simple 
handshaking protocol can be implemented by intro- 
ducing new A-abstractions and using the functions 
wait :: SyncToken -> ST s (), which is strict in 
its SyncToken argument and in the state, and ready 
:: ST s SyncToken, which is strict in the. state s. 
SyncToken may be any non-empty type, for example 
type SyncToken = () will do. 
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The missing case in the definition of rule (6) for 
split is specified in Fig. 5. Before any read or write 
operation in a) in the first slice can be executed, wait 
Q has to receive a SyncToken through the variable 
Q. Then it performs a}, signals ready through vari- 
able &, and continues with r;. Likewise the second 
slice first signals on { that it is ready to perform rz, 
but rz cannot proceed before wait % has received its 
SyncToken through %. Depending on the context of 
the slices and the least effect of r; and rz, part of the 
protocol may be omitted. 

The same synchronization problem occurs if two 
references which are manipulated by different slices 
may be aliases of one another. Two references are 
not aliased if their terminator types cannot be equal. 
In the case of references which may be aliased the 
original sequence of their update actions must be re- 
tained using the mechanism outlined above. 


9 Related Work 


Following Moggi [Mog89], Wadler [Wad90, Wad92] 
advocates the use of monads to express state-based 
computations in functional programming. Peyton 
Jones and Wadler [PW93] have used the state monad 
to ensure proper sequencing of I/O operations and 
assignment operations on references. 

Launchbury describes a lazy implementation of 
mutable arrays and variables in terms of a sequenc- 
ing monad [Lau93]. The independence of different in- 
carnations (and thus referential transparency) of the 
sequencing monad is ensured by assigning each se- 
quencing thread a unique identity. Each operation 
must first check the identity in order to guarantee 
absence of side-effects. This expensive check is not 
necessary using our approach where the type checker 
ensures matching identities. More recent work of 
Launchbury and Peyton Jones [LP94] also avoids the 


split(T, V1, V2, [(a1) & A(z)  (a2)]) 


= let M = least-effect(a;) in 
if TAM#O and MT then 


let 2 and Q) be fresh variables in 
let (i, W1, W2, 71, T2) = split(ty, [((z), (2, (V1))) 1, [(B, (V2))], a2) 


in (i,Wi, W2, 


[wait § > A() 9 (a1) > A(z) S ready D AR (r1)], 
[ready > AQ — wait 2D A() — (72)}) 


else ... 


Figure 5: Synchronization for split . 


check and achieves the encapsulation (as stated un- 
der 1. above) by introducing a constant with a rank-2 
polymorphic type. 

Hudak [Hud93] describes several methods for 
defining mutable abstract datatypes which encap- 
sulate single-threaded computations and which are 
amenable to implementation with assignments. He 
generates the specification of a mutable abstract 
datatype from the specification of an immutable one 
if it obeys a linearity condition. He proposes first- 
class references but does not address the problem of 
escaping references. 


Jones and Hudak [JH93] propose a monadic frame- 
work for parallel functional programming. The source 
of parallelism in their work is an unsafe function fork 
where every use must be proved not to introduce side 
effects. In our work fork is introduced by a trans- 
formation and is thus correct once the correctness of 
the transformation is established. 


Chen and Odersky [CO93] describe a stratified type 
system for Avar [ORH93], a lambda calculus extended 
by imperative features. The system has a type re- 
construction algorithm. It is not capable of handling 
nested state transformers which compute state trans- 
formers themselves. The type system proposed here 
provides that capability. Furthermore, Avar is much 
more strict than our intended semantics. In Avar, a 
state-based computation can only return a value after 
all operations (assignments and reads) on the state 
are completed. State transformers can return partial 
results since they implement lazy state and can defer 
some operations on the state. 


Swarup, Reddy, and Ireland [SRI91] have defined a 
calculus which extends the lambda calculus by refer- 
ence variables and operations on them. The absence 
of side-effects in the calculus relies on a stratified 
type system which distinguishes pure expressions, ob- 
servers, and mutators. The stratification makes sure 
that no references can escape from their scope, but 
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also that no observers can be constructed impera- 
tively (which is possible in our work). Since the 
programming style in their calculus is strongly influ- 
enced by continuation-passing style, it is questionable 
whether parallelization can be achieved solely by pro- 
gram transformation, as suggested here. 

Smetsers et al. [SBvP93] describe a uniqueness type 
system for term graph rewrite systems. If a node of a 
redex can be assigned a unique type the correspond- 
ing node can be updated destructively, z.e. it can be 
reused in the contractum. They achieve a similar ef- 
fect, the ability to do computations with assignments, 
by quite different means. 


10 Conclusion 


The paper presents further evidence for the power 
of the monadic approach to integrate first-class ref- 
erences to mutable objects in purely functional pro- 
gramming languages. The concepts of upward and 
downward abstract types allow a high degree of con- 
trol over the lifetime of references. References are 
safely confined to their creating thread, while “freez- 
ing” a mutable object to an immutable one means to 
let a reference escape in a controlled way. Parallelism 
can be introduced in the sequential state monad by 
an effect-directed program transformation which au- 
tomatically exposes implicit parallelism. It seems un- 
likely that a similar transformation is possible for 
continuation-based approaches. 

Downward and upward abstract types can also be 
used to ensure encapsulation and termination of ref- 
erences for other mutable abstract datatypes, for ex- 
ample the direct style and the continuation-passing 
style mutable abstract datatypes of Hudak [Hud93]. 

The automatic extraction of independent parts of 
state threads as shown in Sections 5.2 and 7 does 
not depend on our specific encapsulation mechanism, 
it works as well with the encapsulation proposed by 


Launchbury and Peyton Jones [LP94]. 


A Operational Semantics 


The intended setting for the development in the main 
text is an enriched lazy A-calculus. Its syntax is given 
by 


A s=K |X| (AX.A)|(A A) | let X=AinA 


where X is an infinite set of variables and K is a set 
of constant symbols each with a specific arity (a nat- 
ural number). The usual conventions for omitting 
parentheses apply throughout (application associates 
to the left and the scope of an abstraction extends as 
far to the right as possible). 

The operational semantics is defined by graph 
rewriting as originally proposed by Wadsworth 
[Wad71], see also [Pey87]. Graphs are rewritten ac- 
cording to the functional strategy [KSvP93] which 
enriches priority-based term graph rewriting with 
demand driven rewriting due to pattern matching. 
Graph nodes are labelled with constants, variables, 
Ax, or @ (application) and each node has a list of suc- 
cessors. The number of successors corresponds to the 
arity of the label (the arities of variable nodes, Ax 
nodes, and @ nodes is 0, 1, and 2, respectively). 

An expression e € A is translated into a rooted 
graph as follows: a constant k or a variable x results 
in a node labelled k or x, an abstraction Ax.e results 
in a (root) node labelled Ax with the graph for e as 
the only successor, an application (e; e2) results in 
an application node (the root) with the graphs for e) 
and e2 as successors, the graph for let x = e; in e2 
consists of the graphs for e; and e2 where the root is 
the root of e2 and every link to a free occurrence of 
x in e; and e2 replaced by a link to the root of e}. 

The functional strategy starts at the root of a graph 
searching for a redex. A redex is a subgraph, either a 
B-redex (Ax.e2)e; (an application of an abstraction) 
or a rule-redex f d;...dy (an n-fold applcation of a 
nullary constant to arguments). If neither is found 
the graph is not reduced any further. A {-redex is 
replaced by a fresh copy of the body e2 with every 
link to a free occurrence of x replaced by a link to e}. 
In case of a rule-redex the rules for f are considered 
in textual order. In each rule the argument patterns 
on the left hand side are considered from left to right. 
The nodes of each argument pattern are considered 
recursively. Recursion stops if the considered node is 
a variable. If it is labelled with a constant, the rewrit- 
ing process is applied recursively to the corresponding 
argument node of the redex. Then the successors of 
the argument node (if any) are considered recursively. 
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We assume that there are distinct constants 
CREATE, SELECT, UPDATE, RESULT € K with associated 
rules to implement the operations on references. The 
rules will be described graphically, with the conven- 
tion that special symbols @ (label of an application 
node), (,) (label for a pair constructor), () (the unit 
tuple) and symbols written in upper case letters are 
constant labels, whereas lower case letters denote ar- 
bitrary nodes in the graph. When some node from 
the left hand side of a rewriting rule is reused on the 
right hand side it is labelled with a number as in 1:x. 
If the label of such a node changes it is overwritten in 
the rewriting step. All other nodes are created afresh. 


1:@ = tex ,) 
Ss a 
1:@ => Listes) 
Recaro) 
sh 
1:@ > Tok,) ZR 
aa ae ae 
aie, 
mie he 
1:¢@ > SCY 
Q 3:8 2:6 3:s 
RESULT 2:6 


Notice that the state argument in the rules for select 
and update is a data constructor, 1.e. a constant 
which must be matched éxplicitly. Hence reduction of 
one of these rules forces the evaluation of the state. 
On the contrary, reduction of the rules for create 
and result do not force the evaluation of the state. 
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Abstract 


We propose composable references as tools to handle mutable data structures in monadic- 
style functional programs. They enable us to express mutable data structures efficiently, for 
example, to avoid unnecessary indirections and to avoid copying. A composable reference is a 
reference which is parameterized over the type of the underlying mutable data structure used 
as the state and intuitively is a location of a field (or more generally, a substructure) relative 
to the parameterized state. Composable references can be composed as functions. Composable 
references make stateful programs concise by allowing mutable data structures to be passed 
implicitly. 


1 Introduction 


The notion of multiple mutable objects or references was a problematic issue in purely functional 
languages such as Haskell, when the monad of state transformers [Wad90, Wad92] was introduced 
to express stateful computations, that is, to enable in-place updating while retaining referential 
transparency. Some solutions have been proposed to this problem and some of them, notably that 
of Launchbury and Peyton Jones {LP94], have been already incorporated into existing implemen- 
tations. In their proposal, however, only two data structures (MutVar (reference cells) and MutArr 
(mutable arrays)) are essentially mutable. 

Based on these works, in this paper, we propose a way to deal with general data structures such 
as tuples and lists with mutable components. These are different from those data structures whose 
fields are of MutVar type in the sense that we need indirections in the latter as is shown in Figure 2. 
Mutable objects should have representations as efficient as those used in conventional imperative 
languages (such as C). Caml Light [Ler93] has already such mutable data structures, but it is a 
strict, impure language and referential transparency does not need to be maintained. 

A composable reference intuitively stands for a location of a mutable field (or a substructure) 
relative to the mutable data structure such as tuples and cons cells and is parameterized over 
the type of the mutable data structure. We use composable references in order to access fields 
(substructures) of mutable data structures. State transformers are written relatively to mutable 
data structures used as local states and then are composed with composable references. We can 
also compose two parameterized references when the intermediate mutable data structure contains 
another mutable object as its substructure as we can compose two functions f ::a ~ bandg::b—c 
using function composition (0). Then we can construct stateful programs hierarchically. 
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Composable references allow substructures of mutable data structures to be passed to stateful 
functions which expect the type of these substructures without creating actual copies of these 
substructures. This means that composable references can play a role which cast operators play in 
e.g. C in the sense that both are used to coerce mutable objects into another data type in order to 
access their substructures without actually creating their copies. 

Though we discuss in the context of a lazy language with overloading, there appears to be 
no essential dependency upon evaluation strategies. The technique used in this paper should be 
applicable both to strict languages such as ML and to lazy languages such as Haskell. Monads 
(and therefore the work presented here) can be useful also for strict languages. The reason is as 
follows. First, we do not need weak type variables as is pointed out in [PJW93]. Second, we have 
more opportunities to find type errors; we can not place expressions which have no side effect where 
those with side effect are expected. And last, we can distinguish the pure functional parts from the 
imperative parts. 

In this paper, we assume some familiarity with the Haskell syntax. In the remainder of this 
section, we review related works. 


1.1 Monadic operators 


- Monads provide a uniform framework for various forms of sequential computations (i.e. those with 
side effect) and have been popularized in functional programming community. In this paper, we do 
not get into details and only introduce some monadic operators which are used to express stateful 
computations. Figure 1 explains the monad of state transformers. 

For examples and motivations, see [Mog89, Wad90, Wad92]. The two monads used here — the 
monad of state transformers and the monad of state readers — are in fact families of monads which 
differ only in the type of the state. In-place updating is crucial in stateful computations. The 
designer of primitive stateful operators must carefully hide states from programmers so that they 
can not duplicate states. The monad of state transformers is considered to be a nice abstraction 
for this purpose. The implementation of the ST and SR monad is hidden so that only predefined 
operators are applied to states and that programmers never duplicate pointers to data structures 
which represent states. Then the designer must implement carefully read and write primitives. 


1.2 Launchbury and Peyton Jones 


When monads were introduced to functional programming, it was problematic whether it was 
possible to manipulate more than one piece of mutable object. In order to solve this problem, 
Launchbury and Peyton Jones proposed the primitive operator newVar [LP94] which creates new 
reference cells (of type MutVar): 


newVar :: a -> ST s (MutVar s a) 
and associated operators readVar and writeVar: 


readVar :: MutVarsa-> STsa 
writeVar :: MutVar sa->a-> STs () 


Here, MutVar is parameterized over the type of the state. This parameterized type of the state is 
used in a special typing rule which prevents references from escaping their scopes made by runST. 


runST*: ?°Vae-(Vss°ST ’s"a) => a 
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-- the monad of state transformers 
data ST s a = MkKST (s -> (a, s)) 


returnST :: a-> ST sa 
returnST a = MkST (\ s -> (a, s)) 


thenST :: ST sa-> (a -> STs b) -> STS b 
(MkST m) ‘thenST‘ k = MkST (\ sO -> let (a, si) =m sO; MkST m’ = ka 
in m’ s1) 


-- the monad of state readers. 
data SR s a = MkSR (s -> a) 


returnSR :: a-> SRsa 
returnSR a = MkSR (\ s -> a) 


thenSR :: SR sa-> (a -> SRs b) -> SRS b 


(MkSR m) ‘thenSR‘ k = MKSR (\ s -> let a=mos; MkSR m’= ka 
in m’ s) 


Figure 1: Monadic Operators 


When runST is applied to a state transformer, it passes an initial “empty” state to the state 
transformer and then extract the result. In this way runST makes it possible to extract a “pure” 
value from a stateful computation. The typing rule above is necessary because otherwise a reference 
(MutVar) created in one “state thread” could be used in another thread by mistake and because 
detecting errors caused by such cross pointers in runtime would be expensive. 

There are, however, only two data structures which are essentially mutable (mutable cells and 
mutable arrays). There is no other primitive mutable structures such as pairs, lists and records. 
These are different from data structures whose fields are of MutVar type, for we need indirect cells in 
the latter. This situation is illustrated in Figure 2 which compares two representations of mutable 
lists. Using reference cells, the tail part of a cons cell can not directly point to another cons cell. 
This is problematic when we need an efficient representation of mutable graph structures. What 
is lacking seems to be an appropriate method to handle such primitive mutable data structures. 


1.3. Concurrent Clean 


In [AvGP93], Achten, van Groningen and Plasmeijer proposed Unique types to ensure uniqueness 
of data structures and thus to make in-place updating possible. Though this is an approach quite 
different from using monads, unique types in Concurrent Clean are another motivation of this work. 
Because data structures which represent states are passed around explicitly, we can use a hierarchy 
of states to write modular programs and to separate non-interfering parts of a program so that they 
can run in parallel. On the other hand, there is no notion of references and this makes mutable 
graph structures with shared nodes difficult to handle. We must imitate mutable graph structures 
by using, for example, an integer as an identity of a node, which is, at least, inefficient. 
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The desirable representation of mutable lists 


Figure 2: Comparison (The shaded parts are mutable.) 


2 Composable references 


It is unrealistic to define primitive read/write operators for each field of each data type in order to 
handle mutable data structures such as tuples, lists and records. We need a set of primitives which 
is as small as possible. We will use composable references in order to make use of these primitives 
to handle general mutable data structures. 


2.1 Operators for composable references 


As is said in the introduction, a composable reference intuitively means a location of a field or a sub- 

structure relative to the data structure such as tuples and records used as a state. In the following, 

we will explain how they interact with state transformers and how they should be implemented. 
We think of composable references (CR) as an abstract data type with the following operations: 


(-'>) :: CRs t->STtx->ST sx 
(-?>) :: CRs t->SRtx-> SRS x 
(-*>) :: CRst->CRtu-> CRs u 


We can think of composable references as generators of monad morphisms between state transform- 
ers. Monad morphisms are functions between two monads with some pleasant properties. For the 
definition and examples, please refer to e.g. [Wad90]. We assume these operators bind tighter than 
‘thenx‘ and associate to left. We use these operators to compose stateful programs. The meanings 
of these operator are as follows. When CR s t, which means a relative location of a substructure of 
type t in s, and ST t x, which is a state transformer for type t, are combined by (-!>), the result 
is a state transformer for type s which, however, only modifies the substructure of type t pointed 
by the composable reference. The result of the composition of CR s t and CR t u by (-*>) is the 
relative position of the substructure of type u with respect to the structure of type s. 

This means that state transformers are written with respect to local states and that we pass 
data structures which are used as local states implicitly to state transformers. It seems that the 
implicit style is generally preferred because it allows us to write concise and modular codes as 
experiences in object-oriented programming suggest. In addition, we can separate non-interfering 
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eS 


data CR s t = MKCR (s -> (t, t -> s)) 


MkST (\ s -> let (t, t2s) =rs 
(xiet’)s Mi stht 
init(x,/ t2s t?.)) 


(MkCR r) -!> (MKST st) 


(MKCR r) -?> (MKSR sr) MkSR (\ s -> let (t, _) = rs 


in sr t) 
(MKCR r) -*> (MkKCR q) = MKCR (\ s -> let (t, t2s) =rs 
Clneuzc) sede t 


inn(usyl t2seu2t) ) 


$0Ra-:)? .CRrava 
idR = MCR (\ a -> (a, id)) 


Figure 3: An implementation of CR 


Figure 4: A diagram notation of CR 


parts of a stateful program as in Concurrent Clean. This might be useful for parallelizing execution 
of stateful programs. 

We will use the code of Figure 3 to specify composable references and various operations upon 
composable references and state transformers. When a composable reference (of type CR s t) is 
applied to a data structure (of type s), the result is a pair of an extracted substructure (of type 
t) and a put-back function of type t -> s. This extracted state is passed to a state transformer 
((-!>)) or another composable reference ((-*>)). If we use the diagram notation of [LP94], a 
composable reference and associated operators would be expressed as in Figure 4. 


2.2 Composable references for field access 


As state transformers can be implemented so that they can do in-place updating by restricting 
their expressiveness, composable references can be implemented so that they do not need to create 
actual copies of substructures as far as the layout of data structures allows. We will consider only 
such composable references in the following. Let us consider the following composable references 
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for pairs. 


fstI :: CR (a, b) (Maybe a) 


fstI = MkCR (\ (a, b) -> (Just a, \ (Just a’) -> (a’, b))) 
sndI :: CR (a, b) (Maybe b) 
sndI = MkCR (\ (a, b) -> (Just b, \ (Just b’) -> (a, b’))) 


Here Just is used in order to emphasize that Just a is (a pointer to) a cell containing only one 
field which, in turn, represents a. In other words, we need to perform a dereference to obtain a 
from Just a. 


data Maybe a = Just a | Nothing 


The constructor Nothing may be useful for erroneous situations but is not used in the following. 
It is used here just to convince ourselves that Just is not implemented as noop. 

In a naive implementation, we allocate a new Just cell, pass it to a state transformer and 
then copy the content of the modified Just cell into the corresponding field. However, since state 
transformers are designed so that they update states destructively and the modified Just cell is not 
used elsewhere, we can implement fstI and sndI as functions which takes as an argument a pointer 
to a pair and then simply add the corresponding offsets then pass the result to state transformers. 
Generally, composable references which represent the location of a field can be implemented as 
functions from a pointer to a pointer. 

What kind of composable references can be offered depends on the layout of data structures. We 
make some assumption about the representation of data structures. A constructor with n arguments 
is represented as a contiguous memory area of length n plus those for the header. Components 
are laid out in the same order as the user declared. Tags are included in the header area. When 
tags are not necessary to distinguish variants, tags are not used. For example, List ((]) has two 
variants Cons (:) and Null ((]). But Null has no argument and therefore does not need to be 
heap-allocated. It can be represented as a small integer (typically, 0) that can be distinguished 
from pointers to heap-allocated cells (Cons cells, in this case). 


‘2.3. Composable references as cast operators 


It is also possible to regard the first and the second components of a triple as a pair and define the 
corresponding composable reference as: 


pair’ ssCRe Calf" by c) Cay" b) 
pairs=) MECR *C\ “Calo fc) ep atCas NON May) tea Dec) yy 


Then this can be also implemented without copying and be used to cast a triple into a pair; it 
allows a substructure of a (mutable) triple to be passed to a state transformer which expects a 
pair as a state and therefore acts as a cast operator. Such an ability is essential for mutable data 
structures. Otherwise substructures of mutable objects must be explicitly copied, which reduces 
the usefulness of mutable data structures significantly. 

In practice, we need to name a primitive composable reference for each field when we define a 
new data structure. For example, a possible syntax would be as follows. 


record Point = MkPoint (xCoord :: Int) (yCoord :: Int) 
record ColoredPoint = MkCPoint {inherit pointOf :: Point} (color :: Color) 
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class s :: PairClass a b where 1.1 :: CRs all2:: CRs b 


instance (a, b) :: PairClass (Maybe a) (Maybe b) where 
1.1 = MKCR (\ (a, b) -> (Just a, \ (Just a’) -> (a’, b))) 
1 3) SUMKCR 80 \n (ae Die 3h JUS te Deg a Ust.D Jenoe la, ob’ ))) 


class s :: PairClass a b => s :: TripleClass a b ¢ where 
lo nu Gods .C 


instance (a, b, c) :: PairClass (Maybe a) (Maybe b) where 
Peer Mech CN Colab. C) 2° Clete |. (lust A’ je => (a? ob. c)),) 
ere Seu roR, (\ ta oP, Clie usceo We (Just b?) => Ca. bi. ¢).).) 


instance (a, b, c) :: TripleClass (Maybe a) (Maybe b) (Maybe c) where 
TeATeOMeCh OU (Al Deicide (dust co ON. (lUSt Cc?) => (a. bo c?))) 


Figure 5: Codes for tuples 


Then primitive composable references xCoord, yCoord, pointOf and color should be generated 
automatically. For example, 


pointOf :: CR ColoredPoint Point 


We intend here that ColoredPoint is not isomorphic to (Point, Color) but to (Int, Int, 
Color). 

In many cases, we can avoid the typing problems of heterogeneous aggregates as far as their 
elements can be treated as references because we can cast them into a single data type to hide 
unnecessary parts and because we do not need to extract elements from such aggregates after their 
contents are modified. Instead, we can access the modified state via the same references which are 
initially passed to aggregates. 

Suppose we have pt :: CR s Point and cpt :: CR s ColoredPoint, then pts = [pt, 
cpt-*>pointOf] has type [CR s Point]. 

It seems desirable to express pts without explicit coercion as pts = [pt, cpt]. But this will 
need an extension of the type system. 

In [Lau93], Laufer used first-class abstract types in order to express heterogeneous aggregates. 
However, we can not access additional fields any longer once they are packed as an abstract type. 
We avoid this problem by regarding elements of aggregates as references and using composable 
references to cast elements. 


2.4 Parametric type classes 


We can use parametric type classes as is shown in Figure 5 in order to overload composable 
references which are used to access fields. The notion of parametric type classes [CHO92] is a 
generalization of type classes. We write a placeholder type variable (a type variable which is 
constrained by the class) before “::” and parameters after the name of the class. 

We will use hereafter 1.1, 1.2, 1.3 and so on for references of components of n-tuples, as in 
SML we can use #1, #2 as field selectors for n-tuples. 
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In the original proposal, there can be no more than one instance declaration of the same top 
level type constructor for the same type class even if their parameters differ. For example, the 
following is not allowed: 


instance [Int] :: List Int where ... 
instance [Char] :: List Char where ... 


This is a restriction specific to Haskell-style type classes and can be eased when used in Gofer-style 
type classes [Jon92]. Therefore we will not follow this restriction in the following. We can declare 
types with the same top level constructor as instances of a class, as far as they do not overlap. 
Otherwise, we would need superfluous type constructors. 


2.5 Read and write operators 


Primitive state transformers which read and write states are specified as follows. We will use 
these operators and composable references to define state transformers for general mutable data 
structures. 


fetch :: ST (Maybe a) a 
fetch = MkST (\ (Just a) -> (a, Just a)) 


assign :: a -> ST (Maybe a) () 
assign a = MkKST (\ (Just _) -> ((), Just a)) 


read :: SR (Maybe a) a 
read = MkSR (\ (Just a) -> a) 


In practice, these operators are offered as primitives so that they can do in-place updating. We 
must ensure that fetch should complete dereference before the state is modified by the succeeding 
state transformers. A similar attention should be paid to read when it is used within the following 
operator. 


-- a monad morphism from SR to ST 
Yo: : SRyspag=rs5t) sha 
ro (MkSR r) = MkST (\ s -> (rs, s)) 


We will need freeze operators which make a snapshot of a mutable object for each data type. The 
precise implementations differ according to the type; they depend on the size of objects. Therefore 
we should declare a type class. Note that freeze is an overloaded version of freezeArr of [LP94]. 


class Plastic s where 


freeze :: ST ss 
replace :: s -> STs () 
freezeR :: SR ss 


Then we declare instances for this class. 


instance Plastic (a, b) where 
freeze = 1_1 -!> fetch ‘thenST‘ \ a -> 
Liz ~§> "fetch “thensT* \ib -> 
returnST (a, b) 
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replace (a, b) = 1.1 -!> assign a fehenStT! \iai-> 
1.2 -!> assign b 
freezeR =... 


We need primitive state readers that inspect tags when we define this kind of operators for variant 
(union) types. However, we will not consider general variant types in what follows. We will only 
consider data types which have only two constructors one of which represents the “Null” value. We 
assume that the following overloaded operator is defined for such data types. 


class Null s where 
nullSR :: SR s Bool 


If the state is null, nul1SR returns True. Note that we offer no operator which can change tags 
of mutable variant data structures so that we can always pass state transformers pointers which 
directly point to a contiguous memory area consisting of fields, not to a cell containing a pointer to 
such an area. Then the representation of “pointers” which are passed to state transformers is the 
same as ordinary (non-mutable) data structures and pointers to structures (records) in imperative 
languages such as C. 

Practically instance declarations of Plastic should be generated automatically by the compiler 
(as those of the Eq class). 


2.6 Create operator 


What about the operator which creates new mutable objects? We will consider the type of the 
global state (state passed by runST) as a special type which can contain, as substructures, any type 
of mutable data structures. We offer the melt operator as a generalization of newVar. 


class Plastic a => Contains s a where 
melt :: a -> ST s (CRV s a) 


We should also think of melt as overloaded since it makes a fresh copy of its argument and returns 
a pointer to the copy. Of course, if the argument of melt is a constructor application, it would be 
possible to avoid copying. 

Contains s a means that the type s is able to create and contain new mutable objects of type 
a as substructures. We assume that the type of the global state has this relation to any type. 
The typing rule for runST should also take this into account; the type of the state of the state 
transformer passed to runST can be constrained by relations of the form Contains _ a. Note that 
it can not be an instance of Plastic. Otherwise the whole global state could be copied. 

Global references (references created by the melt operator) can be expressed as simple pointers 
because they do not need to be relative to something. Therefore we can define equality as pointers 
among them. We provide the type CRV in order to represent simple pointers in the global state. 
More precisely, CRV s t is a primitive data type with the following operators: 


eqCRV see GRV “Bt -> CRV s t.-> Bool 
UNItCRe ::) CRV S ty-> CRysst 


On the other hand, CR is implemented as functions and may involve computations. For example, 
the following operator might be useful. 


deref 2: SR s”(CR s” a) =>° CR’s a 
deref (MkSR sr) = MKCR (\ s -> let (MKCR r) = sr gs inr sg) 
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Then we can think of MutVar type of [LP94] as a CRV to a record with only one component. 


type MutVar s a = CRV s (Maybe a) 


newVar a = melt (Just a) 
writeVar v a = unitCR v -!> assign a 
readVar v unitCR v -!> fetch 


2.7 Mutable lists 
We define the type of mutable lists as follows. 


record ListP s a = ConsP (headP :: a) (tailP :: CRV s (ListP s a)) | NullP 


The tail part must be a reference because we would like the cons cell which is pointed by the tail 
part to be also mutable. Then two or more mutable lists can share the same mutable list as their 
parts, and mutable lists can be even cyclic. 

As is discussed before, CRV is a direct pointer to another cons cell. Therefore the type above has 
the representation almost identical to list structures used in C, that is, the desirable representation 
in Figure 2. 

For example, let us consider the following program. 


melt NullP ‘thenST‘ \ nO -> 
melt (ConsP 1 nO) ‘thenST‘ \ ci -> 
melt (ConsP 2 c1) ‘thenST‘ \ c2 -> 
melt (ConsP 3 c1) ‘thenST‘ \ ¢3 -> 


In this example, c1 is referred to by both ¢2 and ¢3. If the ConsP cell which is pointed by ci is 
modified, this change can be observed from c2 and ¢3. We can make them even cyclic. 


unitCR ci-*>tailP-!>assign c2 


Representing mutable lists in this way is, of course, low-level. However this seems necessary when 
we would like to handle mutable graph structures efficiently. 


3. Virtual record 


There is a subtle problem in handling ListP. A ConsP cell refers to another ConsP cell via a global 
reference. To access the tail part of a ConsP cell, we must access the global state. Let us, for 
example, define the “foreach” function for CR s (ListP s a). 


foreachP :: ST (Maybe a) b -> CR s (ListP s a) -> ST 8s [b] 
foreachP st p = ro (p -?> nullSR) ‘thenST‘ \ b -> 
if b then returnST [] else 
(p-*>headP-!>st ‘thenST‘ \ a -> 
p-*>tailP-!>fetch ‘thenst* 3\ pv => 
foreachP st (unitCR pv) ‘thenST‘ \ as -> 
returnST (a:as)) 
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Here, we must pass around composable references and must access the global state since a ConsP 
cell can behave as a list only when it is used with the global state. This clutters up the program. 
We would like to hide such a detail and like to make it explicit that we are manipulating a mutable 
list. 

We may notice that \ p -> p-*>tailP-!>fetch plays a role similar to composable references 
of type CR (ListP s a) (ListP s a) for it can make another composable reference of type CRV 
s (ListP s a) from that of CRV s (ListP s a). It seems necessary to unify such operators 
with ordinary composable references. One solution is to always regard composable references as 
functions from a global reference to another global reference and to pass such global references 
using a combination of the monad of state readers and the monad of state transformers to hide the 
details. However, it would be better to treat them as if both were composable references and use 
the operators we introduced so far. Then it is as if we were treating a mutable list which contains 
another mutable list as its substructure. We will pursue this strategy in what follows. 

A similar problem arises when we deal with objects of type [CR s a]. In this case, lists 
themselves are not mutable, but they contain references to mutable objects as elements. We can 
also define “foreach” for them. 


foreachV :: ST ab -> [CR s a] -> ST 8 [b] 

foreachV st 0 = returnsT (J 

foreachV st (p:ps) = p-!>st ‘thensT*’’\ a <-> 
foreachV st ps ‘thenST‘ \ as -> 
returnST (a:as) 


Here lists of composable references are also passed explicitly. Another question is whether we can 
cast CRV s (ListP s a) and [CR s b] into a single data type and use them uniformly. 

To achieve these goals, we use mutable data structures which are accessed indirectly. We call 
such indirectly accessed records virtual records. A virtual record is a record with an explicit method 
table. Then we access the state indirectly via the table. For this purpose, we define the following 
data type: 


data Virtual s v = MkVirt vs 


We define composable references for Virtual by using indirect access via a table (represented as 
v above). We use unVirtCR to extract the object which is indirectly pointed, replTbl to make 
another virtual record by replacing the indirect table by another one which is computed both from 
the table part and the state part. Note that method tables of virtual records are never modified 
by state transformers. 

We will not declare virtual records as instances of Plastic because fetch and assign for them 
would be meaningless. 

We define the following type class: 


class t :: Null => t :: ListClass a where 
firetiztechatna 
FOLt ee CR. tt 


foreach :: (s :: ListClass a) => ST ab -> ST s [b] 
foreach st = ro nullSR ‘thenST‘ \ r -> 

if r then returnST [] 

else first-!>st ‘thenST‘ \ x -> 
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virtual :: v -> CR s (Virtual s v) 
virtual r = MkKCR (\ s -> (MkVirt rs, \ (MkVirt _ s’) -> s’)) 


unVirtCR :: (a -> CR s b) -> CR (Virtual s a) b 
unVirtCR f = MkCR (\ (MkVirt as) -> 
let MkCR r = f a; (b, b2s) = rs 
in (b, \ b’ -> MkVirt a (b2s b’))) 


unVirtSR :: (a -> SR s b) -> SR (Virtual s a) b 
unVirtSR f = MkSR (\ (MkVirt as) -> let MkSR sr = f a in sr s) 


replTbl :: (a -> SR s b) -> CR (Virtual s a) (Virtual s b) 
replTbl f = MkCR (\ (MkVirt as) -> 

let MKSR sr =fa 

in (MkVirt (sr s) s, \ (MkVirt _ s’) -> MkVirt a s’)) 


Figure 6: Operators for Virtual data type 


rest-!>foreach st ‘thenST‘ \ xs -> 
returnST (x:xs) 


We can not declare ListP itself as an instance of ListClass. However, we can use a virtual 
record of ListP and the global state, and then declare it as an instance of ListClass. 


type ListPV s a = Virtual s (CR s (ListP s a)) 


instance ListPV s a :: Null where 
nullSR = unVirtSR (\ p -> p-?>null1SR) 


instance ListPV s a :: ListClass (Maybe a) where 
first = unVirtCR id -*> headP 
rest = replTbl (\ p -> p-*>tailP-?>read ‘thenSR‘ \ n -> 
returnSR (unitCR n)) 


Here replTbl is used in order to convert \ p -> p-*>tailP-?>read into a composable reference 
for virtual records. We must use virtual records in many cases since most objects have references to 
other objects as ListP. However simple composable references introduced in the previous section 
will be useful for optimization by making it explicit that some part of a stateful program can affect 
only limited part of the state. 

We can also declare a virtual record of a simple (immutable) list of references of the form [CR 
s a] as an instance of ListClass. 


type ListV s a = Virtual s [CR s a] 


asListV. ::°CR (ListV sya) (ListVis 7a) 
asListV = idR 
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instance ListV s a :: Null where 
nullSR = unVirtSR (\ xs -> returnSR (null xs)) 


instance ListV s a :: ListClass a where 
first = unVirtCR (\ (h:t) -> h) 
rest replTbl (\ (h:t) -> returnSR t) 


Suppose we have pt :: CR s Point and cpt :: CR s ColoredPoint, we can use the following 
as a reference to a list of Point. 


pts = virtual [pt, cpt-*>pointOf] -*> asListV 


In this expression, -*> asListV is necessary because the type inference algorithm infers too 
general a type and fails to conclude that it is an instance of ListClass. 
We can freely interleave pts with pt and cpt. For example: 


pts -!> foreach (move 12) ‘thenST‘ \ _ -> 
pt -*> xCoord -!> fetch "thenst \) a => 
cpt -*> color -!> assign Red ‘thenST‘ \ b -> 
pts -!> foreach (move 3 1) 


where move :: Int -> Int -> ST Point (). The effect of actions on pts are visible from pt and 
cpt, and vice versa. 

As an attempt to standardize two representations of ListClass, for example, we define the 
following data type. 


data ListS s a = MkListS (SR s Bool) (CR s a) (SR 8s (ListS s a)) 
type ListSV s a = Virtual s (ListS s a) 


We can declare ListSV s a as an instance of ListClass and coerce both [CR s ...] and CR s 
(ListP s ...) into this data type. This is shown in Figure 7. Then it is possible to handle 
heterogeneous lists of lists, for example, it is possible to apply foreach (foreach (move 1 0)) to 
something like virtual [coerceP ..., coerceV ...]. 

As is shown above, virtual records seem to be useful for standardization of mutable data struc- 
tures. For example, we define for PairClass: 


type PairV s a b = Virtual s (CR s a, CRs b) 


asPairV :: CR (PairV s ab) (PairV s a b) 
asPairV = idR 


instance PairV s a b :: PairClass a b where 
1_1 = unVirtCR (\ (a, b) -> a) 


pairV :: (x :: PairClass a b) => CR s x -> CRs (PairV s a b) 
pairV xr = virtual (xr-*>1_1, xr-*>1_2) -*> asPairV 
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instance ListSV s a :: Null where 
nullSR = unVirtSR (\ (MkListS n _ _) -> n) 


instance ListSV s a :: ListClass a where 
first = unVirtCR (\ (MkListS _ f _) -> f) 
rest repLIbWa(y (MkListS <)_ mysar) 


coerceP :: CRV s (ListP s a) -> ListS s (Maybe a) 
coerceP pv = let p = unitCR pv 
in MkListS (p-?>nullSR) (p-*>headP) 
(p-*>tailP-?>read ‘thenSR‘ \ pv’ -> 
returnSR (coerceP pv’)) 


coerceV :: [CR s a] -> ListS s a 


coerceV xs = MkListS (returnSR (null xs)) (head xs) 
(returnSR (coerceV (tail xs))) 


Figure 7: Instance declarations and operators for ListSV 


Then we can cast all the instances of PairClass into PairV using pairV. This may be necessary 
because we can not cast all the instances of PairClass into Pair because the two fields need not 
be laid out contiguously. 

It would be desirable if we could define a type (constructor) of standard method vectors vp, 
whenever we declare a parametric type class R which is intended as a “record” class. Then we could 
declare Virtual s(vps) as an instance of R. We could use this form as the standard representation 
of a parametric type class. However, it is not clear how we should define such method vectors for 
general classes especially for classes which express recursive mutable data structures. 


4 Conclusion 


We proposed composable references in order to deal with data structures with mutable components. 
Mutable data structures can be represented as efficiently as those used in conventional languages. 
Especially, mutable lists can be represented without indirect nodes. As a consequence, we can enjoy 
both the flexibility of references and the conciseness of records. 

Composable references can be also used to cast mutable objects. This is useful when otherwise 
heterogeneous aggregates are necessary. 

We introduced virtual records in order to handle data structures which contain references as 
their fields. Virtual records are used to hide details and to treat them in a higher level. 

Garbage collections might be problematic because we use pointers into the middle of data 
structures. This might be avoided by passing a pointer to the header and an index from the header 
separately. 
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Abstract 


We study an extension of asynchronous z-calculus where names can be returned from pro- 
cesses. We show that with this simple extension an extensive range of functional, state-based 
and control-based programming constructs can be expressed by macro expansions, similar to 
Church-encodings in lambda calculus. 


1 Introduction 


Most programming languages in use today have some way to express concurrent execution of 
processes — either in the language itself (e.g. Ada {20], Modula-3 [5], Facile [7], CML [23]) or by 
means of a library (e.g. Modula-2’s Process module [28], C++’s thread library [25]). This paper 
proposes a formal basis for reasoning about such languages. 


Traditionally, formal foundations for languages with concurrency constructs come in one of two 
styles. Most commonly, one combines a semantic description for the sequential base language with 
another one for the concurrency primitives. For instance, semantic descriptions of Facile [7] or 
CML [2] define a structured operational semantics for the base language as a special case of a 
larger labeled transition system that also models the concurrent aspects of the language. This style 
of description has the advantage that a semantics of the sequential part of the language can be 
obtained by subsetting. However, the resulting formal systems tend to be large. 


Alternatively, one can use a standard process calculus such as CCS [13] or z-calculus [16] to reason 
about both the base language and the concurrency primitives. An example of this approach is the 
PICT programming language [21] that was designed with asynchronous z-calculus [4] as a basis. 
PICT stays fairly close to the underlying calculus and consequently does not fully support sequential 
programming constructs such as functions or sequential composition. Representing these constructs 
in traditional process calculi requires a global encoding, not unlike a conversion to continuation 
passing style in functional programming’. Examples of such encodings are found in work by Milner 


‘In fact, PICT takes an intermediate approach: There is a notation for function definition, which leaves the result 


channel implicit, but there is no corresponding notation for function calls, so that an explicit result channel argument 
always needs to be passed. In effect, this leads to function definitions in PICT being CPS-converted one at a time. 
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[15] for the case of functions and by Walker [27] or Jones [11] for the case of objects. If our aim 
is to reason about source programs such encodings are undesirable since they are all-or-nothing 
propositions: To reason about one part of a program one must encode everything. 


We would prefer a relationship between programming language and foundation that is similar to the 
relationship between functional languages and A-calculus. There, one is transformed to the other via 
Church-encodings, which are pure macro expansions. In this paper we show that a modest change 
to a standard process calculus is sufficient to capture both call-by-value functional programming 
and imperative programming via similar encodings. The applied x calculus augments asynchronous 
m calculus [4] (which is essentially equivalent to v-calculus [10]) with the ability to return a name 
from a process. Together with standard name restriction this gives us a way to model anonymous 
values in the calculus. It turns out that this is all that is needed to encode essentially all sequential 
programming constructs in a concise and straightforward manner. 


Interestingly, with just seven term formation rules and one reduction rule, applied 7 is more compact 
than calculi for sequential state-based languages [12, 6, 19]. This comparison is not completely fair, 
however, since the encoding into applied 7 gives us only an operational understanding of functional 
and imperative constructs. Much less is known at present about the observational properties of the 
encodings. In general, process contexts discriminate more terms than sequential contexts. Hence, 
source language constructs would need to be encapsulated in some way in order to preserve their 
observational properties, but such an encapsulation is not discussed here. Nevertheless, we believe 
that applied 7 can be useful for gaining semantic intuition about how familiar functional and 
state-based programming constructs should behave when extended to a concurrent setting. 


Related work. We have already mentioned the work on PICT and the encodings by Milner, Walker, 
and Jones. Sangiorgi has argued that the higher-order 7 calculus improves on first-order 7 calculus 
as a foundation for functional programming [24]. In a sense, applied 7’s ability to return a name 
from a process is an alternative to higher-order processes, since \-abstractions can be represented. 
Boudol’s y-calculus [3] tries to generalize both CCS and A-calculus. Like in 4 — and unlike in 
applied  — communicating agents are matched by position rather than just channel name. 


Our process equivalence relation is based on Milner’s and Sangiorgi’s barbed bisimulation [17]. 
We adapt their definitions in a straightforward way to the asynchronous and applied case. Honda 
and Yoshida [9] have shown for an asynchronous calculus that barbed bisimulation has a tractable 
characterization that does not depend on a quantification over contexts. 


The rest of this paper is organized as follows. Section 2 presents an operational semantics for 
applied m. Section 3 defines a notion of process equivalence for the calculus. Section 4 shows 
how functional programming constructs can be encoded in applied 7. Section 5 does the same 
for imperative programming, giving encodings for the essential constructions of state and control. 
Section 6 presents an encoding of applied m in asynchronous 7. Section 7 concludes. 
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2 The Core Calculus 


Syntactic Domains 


Variables DY, & 

Preterms M, NV PSs Xa Variable 
| va.M Restriction 
| 2’y.M Abstraction (Input) 
lay ed, Application (Output) 
| M|N Parallel Composition 
| !M Replication 
} 0 Identity 


We build on asynchronous 7-calculus [4], modulo some minor notational modifications that are 
introduced for making the treatment of function application smoother. There is one extension: 
Processes may evaluate to names, and an arbitrary term instead of a single name may appear as 
the argument of an application. Roughly speaking, an application 2M is evaluated by evaluating 
M to some number of names which are all passed in parallel to the channel z. 


Hence, applied 7 is a rather small variation of a standard process calculus. However, it can also 
be seen as a generalization of A-calculus where the concept of a A-abstraction is generalized in 
two ways. First, applied 7’s abstractions can be used only once, unless they are prefixed by a (!) 
replicator. This is similar to the role of abstractions in linear A-calculus [1]. Second, an abstraction 
and its argument are matched by name rather than by position. Fresh local names are introduced 
by a restriction prefix vz (this has also been studied in the context of A-calculus [22, 18]). 


Notational Conventions. fn(M), the set of free names of a term M, is given by 


fn(z) erin 2} fn(vz.M) = fn(M)\{z} 
fn(x’y.M) = {x}U (fn(M)\{y}) fn(cM) = {2}U fn(M) 
fn(M | N) = fn(M)vU fn(N) fn(!M) = fn(M) 
fn(0) =e a 


[x/y]M denotes substitution of x for all free occurrences of y in M. To avoid name capture 
problems in substitutions, we assume everywhere that the free and bound variables of a term and 
all its subterms are distinct. This can always be achieved by a-renaming (see below). 


A note on precedence: Application binds tightest, followed by replication (!) and the binding 
prefixes vz and z’y, followed by parallel composition (|). Application is left-associative and parallel 
composition is associative. Grouping can be changed by using parentheses. 


We also use the words channel and agent interchangeably for name and term, respectively. We 
sometimes contract multiple input or restriction prefixes, using the abbreviations 


Mapa ee se VT. ee Vee. 


Dye, = 2'y1. .-s z'y,.M . 


ds 


Equivalences 


Terms are equivalence classes of preterms. We take syntactic equivalence (=) to be the smallest 
congruence that satisfies the laws below. 


1. Variables can be a-renamed. 


vy.[y/2]M (y /fn(M)) 
z’y.[y/z]M (y ¢in(M)) 


2. Replication composes arbitrarily many copies of a term in parallel. 


(a) vz.M 
(a2) z’2.M 


(Repl) 'M = M | !M 


3. Parallel composition is commutative and associative, with identity 0. 


(Comm) M|N = N|M 
(Assoc) (M|N)|P = M|(N|P) 
(Id) M |0 = M 


4. The scope of a restricted variable z can be extended over parallel composition and application, 
provided z is not captured. Restriction with an unused name has no effect. 


(v-Par) M|vre.N = vz(M|WN) (z ¢/fn(M)) 
(v-Apply) y(vz.M) = va.yM (tr #y) 
(v-Garbage) vz.M = M (z ¢/fn(M)) | 


5. Application distributes over parallel composition. Application has no effect on abstraction 
arguments. 

(Dist) e(M|N) = eM|2N 

(Absorb) t(y’z.M) y’z.M 


tH 


Except for (v-Apply), equalities (1)-(4) all have counterparts in 7-calculus. Equalities (Dist) and 
(Absorb) are perhaps surprising at first. Essentially, they introduce a fundamental asymmetry 
between applications and abstractions. Abstractions are volatile, in that they can move freely into 
and out-of applications. By contrast, applications are stationary, they appear only a single fixed 
context. Note the similarity to first order functional programming, where abstractions correspond 
to function definitions (where the location of the definition does not matter) and applications 
correspond to function calls (where the point of call does matter). However, unlike in functional 
programming, an abstraction can be used only once if it is not replicated. We will see that this 
resource-consciousness is the essential ingredient that allows applied 7 to model side-effects in 
expressions. 


Reduction 


There is a single reduction rule. 


(Reaction ) z'y.M\|az — [z/y|M 
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Reduction is considered modulo syntactic equivalence. Reduction can be applied anywhere in a 
term except under an abstraction or a replication. That is, a binary reduction relation (—) between 
terms is given by the axiom (Reaction) and the inference rule 


M=M M-—wN N=WN' 


(Context) E[M] = BLN) 


where E is an arbitrary evaluation contezt that can be generated by the grammar 
Fo me allem 2g Dy la den Se Be Oo 


Let — be the reflexive transitive closure of reduction. 


3 A Process Equivalence 


Our notion of equivalence of applied + terms is based on bisimulation. The central intuition 
of bisimulation is that an experiment which tests whether two processes are equivalent can be 
constructed from two basic actions: One can observe the interaction of a running process, and one 
can freeze a process in a given state and let in run repeatedly starting from this state. The latter 
distinguishes bisimulation from trace equivalence. 

For processes whose operational semantics is defined by means of a reduction relation, a particularly 
simple form of bisimulation can be devised, which tests only the possibility of interacting on a 
channel, but disregards what is communicated over it. This relation is called barbed bisimulation 
[17]. For applied 7, barbed bisimulation can be simplified further in that only the action of returning 
a name, but not input or output actions, can be observed. This is formalized in the following 


definitions. 


Definition. A symmetric relation R on terms is reduction-closed iff MRN and M — M' implies 
the existence of a term N’ such that N — N’ and M'RN’. 


Definition. A term M converges, written M |}, if M — (xc | N), or M — vz.(z | N) for some 
name z and term NV. 


Definition. A symmetric relation R between terms is a (weak) barbed bisimulation for applied 7 
iff R is reduction-closed and MRN and M J} implies N \}. MAN iff there is a bisimulation R such 
that MRN. 


= is not a congruence, for instance it is not preserved by parallel composition: z’y.0 % z’y.y, but 
not z’y.0 | zz + 2z’y.y | xz. We therefore define: 


Definition. Let = be the largest congruence such that ~C x. 


In the following, whenever we say that two terms M, N are equivalent (written M = N) we mean 
that they are barbed congruent, 7.e. MN. 


he, 


Proposition 3.1 (a) The following are bisimulation equivalences in applied 7. 


z(!M)~= 2M (1) 
Mars Me iM (2) 
vi.z'y.M = 0 (3) 
ve(cy|2z’7z.M) = vzfy/z]M (4) 
yz(zy | '2'z.M) = vz.ly/z]M (5) 

(b) If z ¢fn(M, N, P) then the following are also bisimulation equivalences. 
vre(zM | z'y.zy) = zM (6) 
ve.(zM |2N | !2’y.P) = va.(2M | !z’y.P) | ve(cN | !z’y.P) (7) 
vz('2M | !2’y.P) = !vz.(2M | !z’y.P) (8) 


Equation (1) is the analogue of the (Absorb) equivalence for replicated abstraction. Equation (2) 
says that parallel composition is idempotent on replicated terms. Equation (3) says that any term 
that reads from a freshly allocated variable is an identity for parallel composition. We also call 
such terms inert. Equations (4) and (5) say that reduction via a local variable is an equivalence. 
Equation (6) says that forwarding a term via a local variable is equivalent to sending the term 
directly to its final destination. Finally, equations (7) and (8) are factoring laws for a parallel 
composition or replication of output terms in a local computation. 


4 Encoding Functions 


We now encode functional programming constructs in applied 7, using just macro expansions. We 
define an affine A-abstraction A,z.M, which can be applied at most once, and an unrestricted 
call-by-value abstraction Az.M. 


Az.M & vf.(f | f’z.M) (f fresh) 

\e.M & DPCto ee fetes) (f fresh) 
General function application can be simulated by using a local name for the function part of the 
application. Here we have a choice, whether function and argument part should be evaluated con- 


currently or in sequence. We start with sequential application, which is expressed by juxtaposition 
of function and argument and is encoded as follows: 


MN © vez.(zM | 'z’f.fN) (x, f fresh) 


Application of a channel z is (modulo =) a special case of sequential function application, as is seen 
by looking at the expanded form of rM, i.e. vy.(yz | !y’ f.fM), where y and f are fresh names. 


vy(yx | y’ f.fM) 
ae Vie by (5) 
= «M by (v-GC) 


This explains why we have chosen to use z’ for abstraction and plain z for application, whereas in 
original m calculus plain z is an input prefix amd Z is an output prefix. 
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Example 4.1 


(A, 2.2) (Ary-y) 


def 


Proposition 4.2 


va.(a(vg.(g | g’z.z)) | a’9.gH) 
va.vg.(a(g | g’z.z) | a’g.gH) 
va.vg.((ag | g’z.z) | a’g.gH) 
va.vg.((ag | a’g.gH) | g’z.z) 
va.vg.(gH | g’z.z) 
va.vg.(g(vh.(h | h’y.y)) | g’z.z) 
va.vg.vh.(g(h | h’y.y) | g’z.z) 
va.vg.vh.((gh | h’y.y) | g’z.z) 
va.vg.vh.(gh | g’z.z | h’y.y) 
va.vg.vh.(h | h’y.y) 

vh.(h | h’y.y) 

Avyy 


CueaNyP = MP|NP 

Bae) = MN | MP 

(z’y.M)N = z’y.M 
(IM)N = MN) 


where H © vh.(h | h’y.y) 
by (v-*) 

by (Dist), (Absorb) 

by (Assoc), (Comm) 

by reduction 

substituting the definition of 1 
by various (v) equivalences 
by (Dist), (Absorb) 

by (Assoc), (Comm) 
reducing via g 

by (v-*), (GC) 

by sugaring 


The following are observational equivalences for applied 7. 


The proofs are all simple equivalence chains. Two examples are: (9): 


(M|N)P 


Gar 


vx.(2(M | N) | !2’y.yP) 
vz(zM | 2N | !xz*y.yP) 


ve(eM | 'z’y.yP) | ve(2N | !z’y-yP) 


MP|NP 


(1M) N 


def 


def 


vz.(z(!M) | Iz’ f.fN) 


yz.(!eM | !x’ f.fN) 
eta Mel ey. fy ) 
(M N) 


desugaring the application 
by (Dist) 

by (7) 

resugaring 


desugaring the application 
by (1) 

by (8) 

resugaring 


(9) 
(10) 
(11) 
(12) 


Note that symmetric versions of (11) and (12) do not hold; e.g. in M(z’y.N), the abstraction 


becomes available only after M reduces to a name. 
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Parallel application (e) imposes no sequencing constraints on the evaluation of a function and its 
argument. It is encoded as follows. 


MeN = vz.vy.(2M | yN | 2’ f.y’a.fa) 


Local Definitions 


Using lambda abstraction and application, we can define a let-construct let z = M in N to be sugar 
for (Az.N) M. Expanding this and simplifying yields: 


letz = MinN 
2 (At.N) M 
So ovz(2(vy.(y | 'y’z.N)) | !z?’w.wM) 
= vy(vz.(zy | !z’w.wM) | !y’2.N) 
= vy.(yM | ly’2.N) by (5) . 
As in the A-calculus, this gives us a non-recursive local definition where the variable z cannot 
appear in the body of its defining term, M. Recursive (function) definitions are also possible. They 
can be defined as follows: 
letree fr =MinN © vf(N | !f?z.M) . 
This extends naturally to mutual recursion: 
letrechfrayie Min cen 
Suen fees. N pifievsMial o melliflean we 


5 Encoding Imperative Programs 


Sequential Composition 
We can define the sequential composition of a value-producing term M and aterm N by 
M;N © vad(z2M | 2’y.N) (z,yfresh) . 


This evaluates M until a value is produced, and then continues with NV. The value produced by M 
is discarded. We use the convention that ( ; ) has higher precedence than (| ) but lower precedence 
than the unary operators. 

If in (M,|...| M@,); P each M; produces a value then P will be enabled as soon as one of the M; 


produces its result. We can force a wait for all M;’s by defining a blocking parallel composition ( ||] ) 
of independent subcomputations — this is essentially Hoare’s interleave operator {8]. Interleave is 


expressed as follows: 
M, ||... || Ma & va, ... ty-(2,Mi |... | taMn | t2y, ... 22 yn-()) 


Here, the empty tuple () is a shorthand that stands for some arbitrary reserved name, whose 
identity is unimportant. 
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Dereferencing 


One sometimes wants to use the result of a read operation as an argument in an application. 
Writing z(y’z.z) would not do, as this expression is equivalent to just y’z.z. Instead, one can use 
z(y{) where the read operator ([) is given by: 


zt & va.(a() | 2’y.az.y) . 


Note the role of the acknowledgment channel a. Its purpose can be explained as follows. Clearly, 
to read from a channel z, we need a term of the form z’y.M. The problem is that this term is 
volatile, and hence will reduce in the context of the corresponding output operation. But when 
writing z(z 1), for instance, we want the read value to be passed to z. This is accomplished by 
the pair of the output action a() in the parallel composition and the input action a’z in the reader 
term. Figuratively an interaction via a “pulls back” the abstraction a’z.y into the context of the 
output term a(). A similar technique is used below in the modeling of mutable variables. 


Mutable Variables 


We now encode mutable variables with an allocation operation newref x, where M computes the 
initial value of the allocated result variable, an assignment operation r := z, and a dereferencing 
operation rf. 


newrefz = vr.(r | rz) 
rixz © va.(a()|r’y.(rz | az.x) 
def 


) : 
rf va.(a() | r’y.(ry | a’z.y)) 


These constructs model a mutable variable by a name r that always has a pending output operation 
rz, where z denotes the current value of the variable. Consequently, assignment to a mutable 
variable involves reading out the old value before the new value is written. Likewise, dereferencing 
a mutable a variable involves reading out its value and then writing it back. Note that this makes 
assignment and read symmetric operations, which is reflected in the similarity of their encodings. 


Initializations and assignments with structured terms are derived from these encodings as in the 
case of functions. That is, 


newref M = (Az.newrefz) M = vy.(y’z.newref z | yM) , 
and, analogously, 

r:=M © (Anr:=2z)M = vy(y’z.r:=2|yM). 
Multiple assignments can be expressed by interleaving. 


def 
Pee are =i. Ma Tae Ma ee teeta 
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Example 5.1 The following reduction shows that ( ; ) enforces sequential execution of assign- 
ments. Consider the sequence of assignments r:=1;r:=rf +1 with initial value 0 of r: 


Cr eres etal ae 
def (va.(a() | r?y.(r1 | a?z.1));r:= rf +1) | 70 by desugaring the 
first assignment 
"  ys.(s(va.(a() | r?y.(rl | a?z.1))) | s’d.r:= rf +1) | 70 by expanding the 
sequential composition 


=! )ys.va.(sal)) tan y-(71_j:a°z.1).|_s'd.r t= ef +1.) 70) by various equivalences 
— vs.va.(s(a()) | rl | a’z.1 | s’d.r:= rt +1) reducing via r 

= vs.va.(s(a() | a’z.1) | 71 | s’d.r:=rf +1) by (Dist), (Absorb) 

Si lvsvatsl prin sir :='r 7 41) reducing via a 

— vs.va.(r1|r:=rf +1) reducing via s 


rl|r:srt tl by (GC) 


Control 


We conclude our overview of sequential programming constructs with an encoding of control oper- 
ators abort and call/cc in applied . To make a program M abortable, embed it in the context 


ve.(M | e()) . 


where e is some fresh name. Then abort is given by 


def 
abortr = e'y.z . 


Note the reverse trigger, e(), that gets replaced by the argument z of abort by creating the agent 
e’y.z. Since abstractions are volatile, an occurrence of abort inside an application chain will thus 
react with the top-level trigger e(), thereby returning a result from the program. A similar trick is 


used in the encoding of call/cc: 
call/ec ff & ve.vk.( fk | 'k?x.e?y.x | 'e()) 


This passes a continuation k that captures the current context to the function f. Again, e() acts 
as a reverse trigger that injects the argument of the continuation variable k into the context of the 


call/cc. 


6 Encoding Applied 7 in Asynchronous 7 


Applied z has close relations to asynchronous 7 calculus. We now formalize this statement by 
giving an encoding of applied 7 in asynchronous 7. We use a slight variation of Boudol’s definition. 


In our version, Tasync, terms are given by 
Me = el My Baguette ae ie eee 
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modulo syntactic equivalences (a), (Repl), (Comm), (Assoc), (Id), (v-Par), (v-Garbage) and re- 
duction is as in applied 7. 

As an equivalence theory for asynchronous 7 terms we also use barbed bisimulation, which now 
takes the following form. 


Definition. A term M € Tasync Outputs on a channel z, written M |,, if there is a name y and a 
term N such that either M — zy | N or M + vy.(zy | NV). 


That is, we take as observables output actions, but not input actions. Based on this notion of 
observation, barbed bisimulation and barbed congruence are then defined as usual: 


Definition. A symmetric relation R between terms in Tasync is a (weak) asynchronous barbed 
bisimulation iff R is reduction-closed and MRN and M |, implies N J. MRasyncN iff there is 
an asynchronous bisimulation R such that MRN. let async be the largest congruence contained 
in =. 

We now define a mapping [-] that takes as arguments an applied + term M and a name r and 
yields a term in Tasyne- The name r represents a channel where the result of the translated term 
should be sent to. The translation is given by: 


[z]r =. (17r | 

[vze.M]r = vz.[M]r 

[z’y.M]r = 27(y,s).[M]s 

[zMé]r = vs([M]s | !vt.s’y.(z(y,t) | !t?z.rz)) 
[M|N]r = [M]r| [N]r | 
[!]r EM |r: 


We use for brevity polyadic inputs z’(y,z).M and outputs z(y,z) which can be expanded with 
Honda and Tokoro’s “zip-lock” technique? [10]: 


z’(y,z).M & 2’uve.(uv | v’?y.vw.(uw | w?z.M)) 


z(y, z) 2 oyu(cu | u’v.(vy | u’w.wz)) . 


To show that this encoding is well-defined, have have to verify that it is insensitive to the preterm 
chosen to represent a term. 


Proposition 6.1 Let r be aname. Let M, N be preterms such that M = N. Then [M]r x [N]r. 


Proof Sketch: Verify that the translations of all syntactic equivalence rules are barbed asynchronous 
bisimulations. O 


The following lemma shows that forwarding of a result via an intermediary is indistinguishable 
from passing the result directly: 


Lemma 6.2 Assume s,t /¢fn(M). Then [M]r x vs.([M]s | s’z.rz). 


?Note how parallel compositions in the input term correspond to input prefixes in the output term and vice versa. 
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We now show that the encoding preserves the reduction semantics of applied 7, in the following 


sense: 


Definition. Let M,N € async. M —3yn- N iff there are terms M! Rasyne M and N’ Rasyne N such 
that M’ async N’. 


Proposition 6.3 Let M, N be terms in applied 7 and let r ¢ fn(M,N). If M — WN then 
[Mr soyne LN Ir. 


Proof: Assume M — N and r ¢fn(M,N). Then we have: 


[2z’z.M | zy]r 
= 27(z,s).[M]s | vs.(sy | s’z.vt.(z(z,t) | t’u.ru)) 
= 2°(z,3).({M]s | vt-(z(y,t) | t'ucru)) by local reduction 


vt.({y/z,t/s][M]s | t?u.ru) 
= vt.([{y/z]M]t | t’u.rv) 
[[y/z]éM]r by Lemma 6.2 


| 


0 


Proposition 6.4 Let M, N be terms in applied r. If, for all r ¢fn( M,N), [M]r async [N]r then 
MAN. 


Proof: Assume M # N. Then there is a context C’ such that one of C[M], C[N] converges but 
the other does not. W.l.o.g. assume that C[M] 1}, C[N] ¥. Let a be a fresh name. Then, because 
of Proposition 6.3, [C[M]]a |. but [C[N]]a ¥.. Since the encoding [-] is compositional on terms, 
there is a context D in Tasyne and a name r ¢fn(P) such that [C[P]a] = D[[P]r], for all terms P, 
names a. Hence, D[[M]r] 4 but D[[N]r] ¥.. It follows that [M]r async [N]r. O 


Unfortunately, the other direction of Proposition 6.4 seems to be much harder to prove. Propo- 
sition 6.4 requires that reductions in applied = can be simulated by reductions in asynchonous 7, 
which is guaranteed by Proposition 6.3. The reverse direction would require that every possible 
asynchronous reduction sequence that starts and ends in an encoded applied term simulates a re- 
duction seuquence in applied +. This appears credible, but a formal proof is still missing. We 
therefore can only conjecture that [-] takes equivalences in applied m to equivalences in tT, sync. 


Conjecture Let M, N be terms in applied 7. Let r /fn(M,N). If M = N then [M]r async [N]r. 


7 Conclusion 


We have presented a modification of asynchronous 7 calculus that allows us to model sequential 
programming constructs in a simple way, using just macro expansions. We believe that this proposal 
might evolve into a formal foundation for programming languages that can express concurrent 
execution of processes but at the same time retain their sequential programming heritage. However, 
more work needs to be done until this goal is achieved. 


106 


In particular, we would like to get process equivalence criteria that are more tractable than the 
barbed congruence we have used. Another open question concerns the relationship between the 
process equivalence theory of applied and the corresponding theory of the pure asynchronous 
calculus. Finally, it should be possible to define a typed version of applied 7 by generalizing 
Milner’s sorting approach for 7 calculus [14]. 
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